Open Case Studies : Predicting Annual Air Pollution

Disclaimer: The purpose of the Open Case Studies project is to demonstrate the use of various data science methods, tools, and software in the context of messy, real-world data. A given case study does not cover all aspects of the research process, is not claiming to be the most appropriate way to analyze a given data set, and should not be used in the context of making policy decisions without external consultation from scientific experts.

Motivation

A variety of different sources contribute different types of pollutants to what we call air pollution. Some sources are natural while others are anthropogenic (human derived):

[source]

Major types of air pollutants

1. Gaseous - Carbon Monoxide (CO), Ozone (O₃), Nitrogen Oxides(NO, NO₂), Sulpher Dioxide (SO₂)
2. Particulate - small liquids and solids suspended in the air (includes lead- can include certain types of dust)
3. Dust - small solids (larger than particulates) that can be suspended in the air for some time but eventually settle
4. Biological - pollen, bacteria, viruses, mold spores

See [here])http://www.redlogenv.com/worker-safety/part-1-dust-and-particulate-matter) for more detail on the types of pollutants in the air.

Particulate pollution

Air pollution particulates are generally described by their size.

There are 3 major categories:

1. Large Coarse Particulate Mater - has diameter of >10 micrometers (10 µm)

2. Coarse Particulate Mater (called PM_10-2.5) - has diameter of between 2.5 µm and 10 µm

3. Fine Particulate Mater (called PM_2.5) - has diameter of < 2.5 µm

PM₁₀ includes any particulate mater <10 µm (both coarse and fine particulate mater)

Here you can see how these sizes compare with a human hair:

[source]

The following plot and table show the relative sizes of these different pollutants in micrometers(µm):

[source]

[source]

This table shows how deeply some of the smaller fine particles can penetrate within the human body:

[source]

Negative Impact of Particulate Exposure on Health

Exposure to air pollution is associated with higher rates of mortality in older adults and is known to be a risk factor for many diseases and conditions including but not limited to:

1. Asthma - fine particle exposure (PM_2.5) was found to be associated with higher rates of asthma in children
2. Inflammation in type 1 diabetes - fine particle exposure (PM_2.5) from traffic-related air pollution was associated with increased measures of inflammatory markers in youths with type 1 diabetes
3. Lung function and emphysema - higher concentrations of ozone (O₃), nitrogen oxides (NO_x), black carbon, and fine particle exposure PM_2.5 , at study baseline were significantly associated with greater increases in percent emphysema per 10 years
4. Low birthweight - fine particle exposure(PM_2.5) was associated with lower birth weight in full-term live births
5. Viral Infection - higher rates of infection and increased severity of infection are associated with higher exposures to pollution levels including fine particle exposure (PM_2.5)

See this review article for more information about sources of air pollution and the influence of air pollution on health.

Sparse Monitoring is Problematic for Public Health

Historically epidemiological studies would assess the influence of air pollution on health outcomes by relying on a number of monitors located around the country. However as can be seen in the following figure, these monitors remain to be relatively sparse in certain regions of the country. Furthermore, dramatic differences in pollution rates can be seen even within the same city.

[source]

This lack of granularity in air pollution monitoring has hindered our ability to discern the full impact of air pollution on health and to identify at-risk locations.

Machine Learning Offers a Solution

An article published in the Environmental Health journal dealt with this issue by using data about population density, road density, among other features to model or predict air pollution levels at a more localized scale using machine learning methods.

Yanosky, J. D. et al. Spatio-temporal modeling of particulate air pollution in the conterminous United States using geographic and meteorological predictors. Environ Health 13, 63 (2014).

The authors of this article state that:

“Exposure to atmospheric particulate matter (PM) remains an important public health concern, although it remains difficult to quantify accurately across large geographic areas with sufficiently high spatial resolution. Recent epidemiologic analyses have demonstrated the importance of spatially- and temporally-resolved exposure estimates, which show larger PM-mediated health effects as compared to nearest monitor or county-specific ambient concentrations.”

The article above explains that machine learning methods can be used to predict air pollution levels when traditional monitoring systems are not available in a particular area or when there is not enough spatial granularity with current monitoring systems. We will use similar methods to predict annual air pollution levels spatially within the US.

Main Questions

Our main question:

1. Can we predict annual average air pollution concentrations at the granularity of zip code regional levels using predictors such as data about population density, urbanization, road density, as well as, satellite pollution data and chemical modeling data?

Learning Objectives

In this case study, we will walk you through importing data from CSV files and performing machine learning methods to predict our outcome variable of interest (in this case annual fine particle air pollution estimates). We will especially focus on using packages and functions from the Tidyverse, and more specifically the tidymodels package/ecosystem primarily developed and maintained by Max Kuhn and Davis Vaughan. This package loads more modeling related packages like rsample, recipes, parsnip, yardstick, and dials. We will also briefly cover the workflows and tune packages. The tidyverse is a library of packages created by RStudio. While some students may be familiar with previous R programming packages, these packages make data science in R especially efficient.

We will begin by loading the packages that we will need:

library(here)
library(readr)
library(dplyr)
library(skimr)
library(summarytools)
library(magrittr)
library(GGally)

library(tidymodels)# broom, dials, infer, parsnip, purrr, recipes, rsample, tibble, yardstick

library(workflows)
library(tune)

# library(stringr)
# library(purrr)
# library(tibble)
# library(tidyr)
# library(ggplot2)
# library(ggpubr)
# library(forcats)
# library(lmerTest)
# library(car)
# library(ggiraph)
# library(ggforce)
# library(viridis)
# library(cowplot)

Package	Use
here	to easily load and save data
readr	to import the CSV file data
dplyr	to view/arrange/filter/select/compare specific subsets of the data
skimr	to get an overview of data
summarytools	to get an overview of data in a different style
magrittr	to use the %<>% pipping operator
GGally	to create correlation plots
rsample	to split the data into testing and training sets and to split the training set for cross-validation
recipes	to pre-process data for modeling in a tidy and reproducible way and to extract pre-processed data (major functions are recipe() , prep() and various transformation step_*() functions, as well as juice() - extracts final preprocessed training data and bake() - applies recipe steps to testing data). See here for more info.
parsnip	an interface to create models (major functions are fit(), set_engine())
yardstick	to evaluate the performance of models

stringr | to manipulate the text within the PDF of the data

purrr | to perform functions on all columns of a tibble tibble | to create data objects that we can manipulate with dplyr/stringr/tidyr/purrr tidyr | to separate data within a column into multiple columns ggplot2 | to make visualizations with multiple layers ggpubr | to easily add regression line equations to plots forcats | to change details about factors (categorical variables) lmerTest| to perform linear mixed model testing car| to perform Levene’s Test of Homogeneity of Variances ggiraph| to make plots interactive ggforce| to modify facets in plots viridis| to plot in color palette that is easily interpreted by colorblind individuals cowplot | to allow plots to be combined ___

The first time we use a function, we will use the :: to indicate which package we are using. Unless we have overlapping function names, this is not necessary, but we will include it here to be informative about where the functions we will use come from.

Context

The State of Global Air is a report released every year to communicate the impact of air pollution on public health.

The State of Global Air 2019 report which uses data from 2017 stated that:

Air pollution is the fifth leading risk factor for mortality worldwide. It is responsible for more deaths than many better-known risk factors such as malnutrition, alcohol use, and physical inactivity. Each year, more people die from air pollution–related disease than from road traffic injuries or malaria.

The report also stated that:

In 2017, air pollution is estimated to have contributed to close to 5 million deaths globally — nearly 1 in every 10 deaths.

##### [source]

The State of Global Air 2018 report using data from 2016 which separated different types of air pollution, found that particulate pollution was particularly associated with mortality.

The 2019 report shows that the highest levels of fine particulate pollution occurs in Africa and Asia and that:

More than 90% of people worldwide live in areas exceeding the World Health Organization (WHO) Guideline for healthy air. More than half live in areas that do not even meet WHO’s least-stringent air quality target.

Looking at the US specifically, air pollution levels are generally improving. The US Environmental Protection Agency (EPA) also releases a report about air pollution levels called Our Nation’s Air.

[source]

However, air pollution continues to contribute to health risk for Americans, in particular in regions with higher than national average rates of pollution that actually at time exceed the world health organization’s recommended level. Thus it is necessary to obtain high spatial granularity in estimates of air pollution in order to identify locations where populations are experiencing harmful levels of exposure.

You can see that current air quality conditions at this website and you will notice variation across different cities.

Here were the conditions in Topeka Kansas when this was written:

It reports particulate values using what is called the Air Quality Index scale (AQI), this calculator indicates that 114 AQI is equivalent to 40.7 ug/m³ and is considered unhealthy for sensitive individuals. Thus some areas very much exceed the World Health Organization (WHO) annual exposure guideline (10 ug/m³) at certain times and this may adversely affect the health of people living in these locations.

Furthermore, adverse health effects have been associated with populations experiencing higher pollution exposure despite the levels being below suggested guidelines. Secondly, it appears that the composition of the particulate mater and the influence of other demographic factors may make specific populations more at risk for adverse health effects due to air pollution. See this article for more details.

The monitor data that we will use in this case study comes from a system of monitors in which roughly 90% are located within cities. Thus there is an equity issue in terms of capturing the air pollution levels of more rural areas. Therefore, to get a better sense of the pollution exposures for the individuals living in these areas, methods like machine learning can be very useful to estimate air pollution levels in areas with little to no monitoring.

Indeed, machine learning methods are in fact used to be able to estimate air pollution in these low monitoring areas so that we can make a map like this where we have annual estimates for all of the contiguous US:

[source]

This is what we aim to achieve in this case study.

Limitations

There are some important considerations regarding this data analysis to keep in mind:

1. The data in our analysis does not include information about the composition of particulate mater. Different types of particulates may be more benign or deleterious for health outcomes.

2. Outdoor pollution levels are not necessarily an indication of of individual exposures. People spend differing amounts of time indoors and outdoors and are exposed to different pollution levels indoors. People are now developing personal monitoring systems to track air pollution levels on the personal level.

Our analysis will use annual mean estimates, however pollution levels can vary greatly by season, day and even hour. There are data sources that have finer levels of temporal data, however we are interested in long term exposures, as these appear to be the most influential for health outcomes, so we chose to use annual level data.

What are the data?

In Machine Learning for prediction, there are two main types of variables:

1. Outcome variable
2. Predictor variables

The outcome variable is what are trying to predict. In building our model we actually have the outcome variable data, but we want to see how well our predictor variables can explain the variation in our outcome data. This gives us a sense of how well we can use the predictor variable data to predict our outcome variable levels when we in fact do not have data about the outcome.

As a simpler example, imagine that we have data about the sales and characteristics of cars from last year and we want to predict which cars might sell well this year. We do not have the sales data yet for this year, but we do know the characteristics of our cars for this year. We can use a model of the characteristics that explained sales last year to estimate what cars might sell well this year. In this case, our outcome variable is the sale performance of the cars, while the different characteristics of the cars make up our predictor or explanatory variables.

In this case study, we will evaluate air pollution monitor data of fine particulate mater (PM_2.5) in the contiguous US from 2008, as well as data about population density, road density, urbanization levels, and NASA satellite data to develop models to predict localized air pollution levels.

The monitor data will be our outcome variable. We want to determine if we can predict air pollution levels based on other types of data, like road density and population density to see if we can use these data to predict air pollution in areas where there are no monitors.

Our outcome variable

The monitor data that we will be using comes from gravimetric monitors operated by the US Enivornmental Protection Agency (EPA). These monitors use a filtration system to specifically capture fine particulate matter. The weight of this matter is manually measured daily or weekly. See here for the EPA standard operating procedure for PM gravimetric analysis in 2008.

[source]

Here is an image of what the gravimetric monitors look like:

Gravimetric analysis is also used for emission testing. The same idea applies: a fresh filter is applied and the desired amount of time passes, then the filter is removed and weighed.

There are other monitoring systems that can provide hourly measurements, but we will not be using data from these monitors in our analysis. Gravimetric analysis is considered to be among the most accurate methods.

In our csv, the value column indicates the PM_2.5 monitor average for 2008 in mass of fine particles/volume of air for 876 gravimetric monitors. The units are micro grams of fine particulate mater (PM) that is less than 2.5 micrometers in diameter per cubic meter of air - mass concentration (ug/m³). Recall the the WHO exposure guideline is < 10 ug/m³ on average annually for PM_2.5.

Our predictor variables

There are 48 predictor variables with values for each of the 876 monitors included in our outcome variable. The data comes from the US Enivornmental Protection Agency (EPA), the National Aeronautics and Space Administration (NASA), the US Census, and the National Center for Health Statistics (NCHS).

Variable	Details
id	Monitor number – the county number is indicated before the decimal – the monitor number is indicated after the decimal Example: 1073.0023 is Jefferson county (1073) and .0023 one of 8 monitors
fips	Federal information processing standard number for the county where the monitor is located – 5 digit id code for counties (zero is often the first value and sometimes is not shown) – the first 2 numbers indicate the state – the last three numbers indicate the county Example: Alabama’s state code is 01 because it is first alphabetically (note: Alaska and Hawaii are not included because they are not part of the contiguous US)
Lat	Latitude of the monitor in degrees
Lon	Longitude of the monitor in degrees
state	State where the monitor is located
county	County where the monitor is located
city	City where the monitor is located
CMAQ	Estimated values of air pollution from a computational model called Community Multiscale Air Quality (CMAQ) – A monitoring system that simulates the physics of the atmosphere using chemistry and weather data to predict the air pollution – Does not use any of the PM2.5 gravimetric monitoring data. (There is a version that does use the gravimetric monitoring data, but not this one!) – Data from the EPA
zcta	Zip Code Tabulation Area where the monitor is located – Postal Zip codes are converted into “generalized areal representations” that are non-overlapping – Data from the 2010 Census
zcta_area	Land area of the zip code area in meters squared – Data from the 2010 Census
zcta_pop	Population in the zip code area – Data from the 2010 Census
imp_a500	Impervious surface measure – Within a circle with a radius of 500 meters around the monitor – Impervious surface are roads, concrete, parking lots, buildings – This is a measure of development
imp_a1000	Impervious surface measure – Within a circle with a radius of 1000 meters around the monitor
imp_a5000	Impervious surface measure – Within a circle with a radius of 5000 meters around the monitor
imp_a10000	Impervious surface measure – Within a circle with a radius of 10000 meters around the monitor
imp_a15000	Impervious surface measure – Within a circle with a radius of 15000 meters around the monitor
county_area	Land area of the county of the monitor in meters squared
county_pop	Population of the county of the monitor
Log_dist_to_prisec	Log (Natural log) distance to a primary or secondary road from the monitor – Highway or major road
log_pri_length_5000	Count of primary road length in meters in a circle with a radius of 5000 meters around the monitor (Natural log) – Highways only
log_pri_length_10000	Count of primary road length in meters in a circle with a radius of 10000 meters around the monitor (Natural log) – Highways only
log_pri_length_15000	Count of primary road length in meters in a circle with a radius of 15000 meters around the monitor (Natural log) – Highways only
log_pri_length_25000	Count of primary road length in meters in a circle with a radius of 25000 meters around the monitor (Natural log) – Highways only
log_prisec_length_500	Count of primary and secondary road length in meters in a circle with a radius of 500 meters around the monitor (Natural log) – Highway and secondary roads
log_prisec_length_1000	Count of primary and secondary road length in meters in a circle with a radius of 1000 meters around the monitor (Natural log) – Highway and secondary roads
log_prisec_length_5000	Count of primary and secondary road length in meters in a circle with a radius of 5000 meters around the monitor (Natural log) – Highway and secondary roads
log_prisec_length_10000	Count of primary and secondary road length in meters in a circle with a radius of 10000 meters around the monitor (Natural log) – Highway and secondary roads
log_prisec_length_15000	Count of primary and secondary road length in meters in a circle with a radius of 15000 meters around the monitor (Natural log) – Highway and secondary roads
log_prisec_length_25000	Count of primary and secondary road length in meters in a circle with a radius of 25000 meters around the monitor (Natural log) – Highway and secondary roads
log_nei_2008_pm25_sum_10000	Tons of emissions from major sources data base (annual data) sum of all sources within a circle with a radius of 10000 meters of distance around the monitor (Natural log)
log_nei_2008_pm25_sum_15000	Tons of emissions from major sources data base (annual data) sum of all sources within a circle with a radius of 15000 meters of distance around the monitor (Natural log)
log_nei_2008_pm25_sum_25000	Tons of emissions from major sources data base (annual data) sum of all sources within a circle with a radius of 25000 meters of distance around the monitor (Natural log)
log_nei_2008_pm10_sum_10000	Tons of emissions from major sources data base (annual data) sum of all sources within a circle with a radius of 10000 meters of distance around the monitor (Natural log)
log_nei_2008_pm10_sum_15000	Tons of emissions from major sources data base (annual data) sum of all sources within a circle with a radius of 15000 meters of distance around the monitor (Natural log)
log_nei_2008_pm10_sum_25000	Tons of emissions from major sources data base (annual data) sum of all sources within a circle with a radius of 25000 meters of distance around the monitor (Natural log)
popdens_county	Population density (number of people per kilometer squared area of the county)
popdens_zcta	Population density (number of people per kilometer squared area of zcta)
nohs	Percentage of people in zcta area where the monitor is that do not have a high school degree – Data from the Census
somehs	Percentage of people in zcta area where the monitor whose highest formal educational attainment was some high school education – Data from the Census
hs	Percentage of people in zcta area where the monitor whose highest formal educational attainment was completing a high school degree – Data from the Census
somecollege	Percentage of people in zcta area where the monitor whose highest formal educational attainment was completing some college education – Data from the Census
associate	Percentage of people in zcta area where the monitor whose highest formal educational attainment was completing an associate degree – Data from the Census
bachelor	Percentage of people in zcta area where the monitor whose highest formal educational attainment was a bachelor’s degree – Data from the Census
grad	Percentage of people in zcta area where the monitor whose highest formal educational attainment was a graduate degree – Data from the Census
pov	Percentage of people in zcta area where the monitor is that lived in poverty in 2008 - or would it have been 2007 guidelines??https://aspe.hhs.gov/2007-hhs-poverty-guidelines – Data from the Census
hs_orless	Percentage of people in zcta area where the monitor whose highest formal educational attainment was a high school degree or less (sum of nohs, somehs, and hs)
urc2013	2013 Urban-rural classification of the county where the monitor is located – 6 category variable - 1 is totally urban 6 is completely rural – Data from the National Center for Health Statistics](https://www.cdc.gov/nchs/index.htm){target="_blank"}
urc2006	2006 Urban-rural classification of the county where the monitor is located – 6 category variable - 1 is totally urban 6 is completely rural – Data from the National Center for Health Statistics
aod	Aerosol Optical Depth measurement from a NASA satellite – based on the defraction of a laser – used as a proxy of particulate pollution – unit-less - higher value indicates more pollution – Data from NASA

Many of these predictor variables have to do with the circular area around the monitor called the “buffer”. These are illustrated in the following figure:

[source]

Data Import

We have one CSV file that contains both our single outcome variable and all of our predictor variables.

Let’s import our data into R now so that we can explore the data further. We will call our data object pm for particulate matter.

pm <-readr::read_csv(here("docs", "pm25_data.csv"))

Data Exploration and Wrangling

The first step in performing a machine learning analysis is to explore the data to better understand the variables included in the data, as we may learn about important details about the data that we should keep in mind as we try to predict our outcome variable.

First let’s just get a general sense of our data. We can do that using the glimpse() function of the dplyr package (it is also in the tibble package).

We will also use the %>% pipe which can be used to define the input for later sequential steps. This will make more sense when we have multiple sequential steps using the same data object. To use the pipe notation we need to install and load dplyr as well.

For example here we will first grab the pm data object, then we use the glimpse() function on it based on the pipe notation.

pm %>%
  dplyr::glimpse()

Observations: 876
Variables: 50
$ id                          <dbl> 1003.001, 1027.000, 1033.100, 1049.1…
$ value                       <dbl> 9.597647, 10.800000, 11.212174, 11.6…
$ fips                        <dbl> 1003, 1027, 1033, 1049, 1055, 1069, …
$ lat                         <dbl> 30.49800, 33.28126, 34.75878, 34.287…
$ lon                         <dbl> -87.88141, -85.80218, -87.65056, -85…
$ state                       <chr> "Alabama", "Alabama", "Alabama", "Al…
$ county                      <chr> "Baldwin", "Clay", "Colbert", "DeKal…
$ city                        <chr> "Fairhope", "Ashland", "Muscle Shoal…
$ CMAQ                        <dbl> 8.098836, 9.766208, 9.402679, 8.5347…
$ zcta                        <dbl> 36532, 36251, 35660, 35962, 35901, 3…
$ zcta_area                   <dbl> 190980522, 374132430, 16716984, 2038…
$ zcta_pop                    <dbl> 27829, 5103, 9042, 8300, 20045, 3021…
$ imp_a500                    <dbl> 0.01730104, 1.96972318, 19.17301038,…
$ imp_a1000                   <dbl> 1.4096021, 0.8531574, 11.1448962, 3.…
$ imp_a5000                   <dbl> 3.3360118, 0.9851479, 15.1786154, 1.…
$ imp_a10000                  <dbl> 1.9879187, 0.5208189, 9.7253870, 1.0…
$ imp_a15000                  <dbl> 1.4386207, 0.3359198, 5.2472094, 0.9…
$ county_area                 <dbl> 4117521611, 1564252280, 1534877333, …
$ county_pop                  <dbl> 182265, 13932, 54428, 71109, 104430,…
$ log_dist_to_prisec          <dbl> 4.648181, 7.219907, 5.760131, 3.7214…
$ log_pri_length_5000         <dbl> 8.517193, 8.517193, 8.517193, 8.5171…
$ log_pri_length_10000        <dbl> 9.210340, 9.210340, 9.274303, 10.409…
$ log_pri_length_15000        <dbl> 9.630228, 9.615805, 9.658899, 11.173…
$ log_pri_length_25000        <dbl> 11.32735, 10.12663, 10.15769, 11.909…
$ log_prisec_length_500       <dbl> 7.295356, 6.214608, 8.611945, 7.3101…
$ log_prisec_length_1000      <dbl> 8.195119, 7.600902, 9.735569, 8.5858…
$ log_prisec_length_5000      <dbl> 10.815042, 10.170878, 11.770407, 10.…
$ log_prisec_length_10000     <dbl> 11.88680, 11.40554, 12.84066, 11.508…
$ log_prisec_length_15000     <dbl> 12.205723, 12.042963, 13.282656, 12.…
$ log_prisec_length_25000     <dbl> 13.41395, 12.79980, 13.79973, 13.559…
$ log_nei_2008_pm25_sum_10000 <dbl> 0.318035438, 3.218632928, 6.57312730…
$ log_nei_2008_pm25_sum_15000 <dbl> 1.967358961, 3.218632928, 6.58191745…
$ log_nei_2008_pm25_sum_25000 <dbl> 5.067308, 3.218633, 6.875900, 4.8876…
$ log_nei_2008_pm10_sum_10000 <dbl> 1.35588511, 3.31111648, 6.69187313, …
$ log_nei_2008_pm10_sum_15000 <dbl> 2.26783411, 3.31111648, 6.70127741, …
$ log_nei_2008_pm10_sum_25000 <dbl> 5.628728, 3.311116, 7.148858, 5.1719…
$ popdens_county              <dbl> 44.265706, 8.906492, 35.460814, 35.3…
$ popdens_zcta                <dbl> 145.716431, 13.639555, 540.887040, 4…
$ nohs                        <dbl> 3.3, 11.6, 7.3, 14.3, 4.3, 5.8, 7.1,…
$ somehs                      <dbl> 4.9, 19.1, 15.8, 16.7, 13.3, 11.6, 1…
$ hs                          <dbl> 25.1, 33.9, 30.6, 35.0, 27.8, 29.8, …
$ somecollege                 <dbl> 19.7, 18.8, 20.9, 14.9, 29.2, 21.4, …
$ associate                   <dbl> 8.2, 8.0, 7.6, 5.5, 10.1, 7.9, 7.3, …
$ bachelor                    <dbl> 25.3, 5.5, 12.7, 7.9, 10.0, 13.7, 5.…
$ grad                        <dbl> 13.5, 3.1, 5.1, 5.8, 5.4, 9.8, 2.0, …
$ pov                         <dbl> 6.1, 19.5, 19.0, 13.8, 8.8, 15.6, 25…
$ hs_orless                   <dbl> 33.3, 64.6, 53.7, 66.0, 45.4, 47.2, …
$ urc2013                     <dbl> 4, 6, 4, 6, 4, 4, 1, 1, 1, 1, 1, 1, …
$ urc2006                     <dbl> 5, 6, 4, 5, 4, 4, 1, 1, 1, 1, 1, 1, …
$ aod                         <dbl> 37.36364, 34.81818, 36.00000, 33.083…

We can see that there are 876 monitors and that we have 50 total variables - one of which is the outcome. In this case our outcome variable is called value.

Notice that some of the variables that we would think of as factors (categorical) are currently of class double as indicated by the <dbl> just to the right of the column names/variable names in the glimpse() output. For example the monitor ID (id), the Federal Information Processing Standard number for the county where the monitor was located (fips), as well as the zcta

Let’s convert these variables into factors. We can do this using the mutate_at() function of the dplyr package and the as.factor() base function.

In this case we are also using the magrittr assignment pipe or double pipe that looks like this %<>% of the magrittr package. This allows us use the pm data as input but also reassign the output to the same data object name.

pm %<>%
  dplyr::mutate_at(vars(id, fips, zcta), as.factor) 

glimpse(pm)

Observations: 876
Variables: 50
$ id                          <fct> 1003.001, 1027.0001, 1033.1002, 1049…
$ value                       <dbl> 9.597647, 10.800000, 11.212174, 11.6…
$ fips                        <fct> 1003, 1027, 1033, 1049, 1055, 1069, …
$ lat                         <dbl> 30.49800, 33.28126, 34.75878, 34.287…
$ lon                         <dbl> -87.88141, -85.80218, -87.65056, -85…
$ state                       <chr> "Alabama", "Alabama", "Alabama", "Al…
$ county                      <chr> "Baldwin", "Clay", "Colbert", "DeKal…
$ city                        <chr> "Fairhope", "Ashland", "Muscle Shoal…
$ CMAQ                        <dbl> 8.098836, 9.766208, 9.402679, 8.5347…
$ zcta                        <fct> 36532, 36251, 35660, 35962, 35901, 3…
$ zcta_area                   <dbl> 190980522, 374132430, 16716984, 2038…
$ zcta_pop                    <dbl> 27829, 5103, 9042, 8300, 20045, 3021…
$ imp_a500                    <dbl> 0.01730104, 1.96972318, 19.17301038,…
$ imp_a1000                   <dbl> 1.4096021, 0.8531574, 11.1448962, 3.…
$ imp_a5000                   <dbl> 3.3360118, 0.9851479, 15.1786154, 1.…
$ imp_a10000                  <dbl> 1.9879187, 0.5208189, 9.7253870, 1.0…
$ imp_a15000                  <dbl> 1.4386207, 0.3359198, 5.2472094, 0.9…
$ county_area                 <dbl> 4117521611, 1564252280, 1534877333, …
$ county_pop                  <dbl> 182265, 13932, 54428, 71109, 104430,…
$ log_dist_to_prisec          <dbl> 4.648181, 7.219907, 5.760131, 3.7214…
$ log_pri_length_5000         <dbl> 8.517193, 8.517193, 8.517193, 8.5171…
$ log_pri_length_10000        <dbl> 9.210340, 9.210340, 9.274303, 10.409…
$ log_pri_length_15000        <dbl> 9.630228, 9.615805, 9.658899, 11.173…
$ log_pri_length_25000        <dbl> 11.32735, 10.12663, 10.15769, 11.909…
$ log_prisec_length_500       <dbl> 7.295356, 6.214608, 8.611945, 7.3101…
$ log_prisec_length_1000      <dbl> 8.195119, 7.600902, 9.735569, 8.5858…
$ log_prisec_length_5000      <dbl> 10.815042, 10.170878, 11.770407, 10.…
$ log_prisec_length_10000     <dbl> 11.88680, 11.40554, 12.84066, 11.508…
$ log_prisec_length_15000     <dbl> 12.205723, 12.042963, 13.282656, 12.…
$ log_prisec_length_25000     <dbl> 13.41395, 12.79980, 13.79973, 13.559…
$ log_nei_2008_pm25_sum_10000 <dbl> 0.318035438, 3.218632928, 6.57312730…
$ log_nei_2008_pm25_sum_15000 <dbl> 1.967358961, 3.218632928, 6.58191745…
$ log_nei_2008_pm25_sum_25000 <dbl> 5.067308, 3.218633, 6.875900, 4.8876…
$ log_nei_2008_pm10_sum_10000 <dbl> 1.35588511, 3.31111648, 6.69187313, …
$ log_nei_2008_pm10_sum_15000 <dbl> 2.26783411, 3.31111648, 6.70127741, …
$ log_nei_2008_pm10_sum_25000 <dbl> 5.628728, 3.311116, 7.148858, 5.1719…
$ popdens_county              <dbl> 44.265706, 8.906492, 35.460814, 35.3…
$ popdens_zcta                <dbl> 145.716431, 13.639555, 540.887040, 4…
$ nohs                        <dbl> 3.3, 11.6, 7.3, 14.3, 4.3, 5.8, 7.1,…
$ somehs                      <dbl> 4.9, 19.1, 15.8, 16.7, 13.3, 11.6, 1…
$ hs                          <dbl> 25.1, 33.9, 30.6, 35.0, 27.8, 29.8, …
$ somecollege                 <dbl> 19.7, 18.8, 20.9, 14.9, 29.2, 21.4, …
$ associate                   <dbl> 8.2, 8.0, 7.6, 5.5, 10.1, 7.9, 7.3, …
$ bachelor                    <dbl> 25.3, 5.5, 12.7, 7.9, 10.0, 13.7, 5.…
$ grad                        <dbl> 13.5, 3.1, 5.1, 5.8, 5.4, 9.8, 2.0, …
$ pov                         <dbl> 6.1, 19.5, 19.0, 13.8, 8.8, 15.6, 25…
$ hs_orless                   <dbl> 33.3, 64.6, 53.7, 66.0, 45.4, 47.2, …
$ urc2013                     <dbl> 4, 6, 4, 6, 4, 4, 1, 1, 1, 1, 1, 1, …
$ urc2006                     <dbl> 5, 6, 4, 5, 4, 4, 1, 1, 1, 1, 1, 1, …
$ aod                         <dbl> 37.36364, 34.81818, 36.00000, 33.083…

Great! Now we can see that these variables are now factors as indicated by <fct> after the variable name.

The skim() function of the skimr package is also really helpful for getting a general sense of your data.

skim(pm)

Data summary

Name	pm
Number of rows	876
Number of columns	50
_______________________
Column type frequency:
character	3
factor	3
numeric	44
________________________
Group variables	None

Variable type: character

skim_variable	n_missing	complete_rate	min	max	empty	n_unique	whitespace
state	0	1	4	20	0	49	0
county	0	1	3	20	0	471	0
city	0	1	4	48	0	607	0

Variable type: factor

skim_variable	n_missing	complete_rate	ordered	n_unique	top_counts
id	0	1	FALSE	876	100: 1, 102: 1, 103: 1, 104: 1
fips	0	1	FALSE	569	170: 12, 603: 10, 261: 9, 107: 8
zcta	0	1	FALSE	842	475: 3, 110: 2, 160: 2, 290: 2

Variable type: numeric

skim_variable	n_missing	complete_rate	mean	sd	p0	p25	p50	p75	p100	hist
value	0	1	10.81	2.580000e+00	3.02	9.27	11.15	12.37	2.316000e+01	▂▆▇▁▁
lat	0	1	38.48	4.620000e+00	25.47	35.03	39.30	41.66	4.840000e+01	▁▃▅▇▂
lon	0	1	-91.74	1.496000e+01	-124.18	-99.16	-87.47	-80.69	-6.804000e+01	▃▂▃▇▃
CMAQ	0	1	8.41	2.970000e+00	1.63	6.53	8.62	10.24	2.313000e+01	▃▇▃▁▁
zcta_area	0	1	183173481.91	5.425989e+08	15459.00	14204601.75	37653560.50	160041508.25	8.164821e+09	▇▁▁▁▁
zcta_pop	0	1	24227.58	1.777216e+04	0.00	9797.00	22014.00	35004.75	9.539700e+04	▇▇▃▁▁
imp_a500	0	1	24.72	1.934000e+01	0.00	3.70	25.12	40.22	6.961000e+01	▇▅▆▃▂
imp_a1000	0	1	24.26	1.802000e+01	0.00	5.32	24.53	38.59	6.750000e+01	▇▅▆▃▁
imp_a5000	0	1	19.93	1.472000e+01	0.05	6.79	19.07	30.11	7.460000e+01	▇▆▃▁▁
imp_a10000	0	1	15.82	1.381000e+01	0.09	4.54	12.36	24.17	7.209000e+01	▇▃▂▁▁
imp_a15000	0	1	13.43	1.312000e+01	0.11	3.24	9.67	20.55	7.110000e+01	▇▃▁▁▁
county_area	0	1	3768701992.12	6.212830e+09	33703512.00	1116536297.50	1690826566.50	2878192209.00	5.194723e+10	▇▁▁▁▁
county_pop	0	1	687298.44	1.293489e+06	783.00	100948.00	280730.50	743159.00	9.818605e+06	▇▁▁▁▁
log_dist_to_prisec	0	1	6.19	1.410000e+00	-1.46	5.43	6.36	7.15	1.045000e+01	▁▁▃▇▁
log_pri_length_5000	0	1	9.82	1.080000e+00	8.52	8.52	10.05	10.73	1.205000e+01	▇▂▆▅▂
log_pri_length_10000	0	1	10.92	1.130000e+00	9.21	9.80	11.17	11.83	1.302000e+01	▇▂▇▇▃
log_pri_length_15000	0	1	11.50	1.150000e+00	9.62	10.87	11.72	12.40	1.359000e+01	▆▂▇▇▃
log_pri_length_25000	0	1	12.24	1.100000e+00	10.13	11.69	12.46	13.05	1.436000e+01	▅▃▇▇▃
log_prisec_length_500	0	1	6.99	9.500000e-01	6.21	6.21	6.21	7.82	9.400000e+00	▇▁▂▂▁
log_prisec_length_1000	0	1	8.56	7.900000e-01	7.60	7.60	8.66	9.20	1.047000e+01	▇▅▆▃▁
log_prisec_length_5000	0	1	11.28	7.800000e-01	8.52	10.91	11.42	11.83	1.278000e+01	▁▁▃▇▃
log_prisec_length_10000	0	1	12.41	7.300000e-01	9.21	11.99	12.53	12.94	1.385000e+01	▁▁▃▇▅
log_prisec_length_15000	0	1	13.03	7.200000e-01	9.62	12.59	13.13	13.57	1.441000e+01	▁▁▃▇▅
log_prisec_length_25000	0	1	13.82	7.000000e-01	10.13	13.38	13.92	14.35	1.523000e+01	▁▁▃▇▆
log_nei_2008_pm25_sum_10000	0	1	3.97	2.350000e+00	0.00	2.15	4.29	5.69	9.120000e+00	▆▅▇▆▂
log_nei_2008_pm25_sum_15000	0	1	4.72	2.250000e+00	0.00	3.47	5.00	6.35	9.420000e+00	▃▃▇▇▂
log_nei_2008_pm25_sum_25000	0	1	5.67	2.110000e+00	0.00	4.66	5.91	7.28	9.650000e+00	▂▂▇▇▃
log_nei_2008_pm10_sum_10000	0	1	4.35	2.320000e+00	0.00	2.69	4.62	6.07	9.340000e+00	▅▅▇▇▂
log_nei_2008_pm10_sum_15000	0	1	5.10	2.180000e+00	0.00	3.87	5.39	6.72	9.710000e+00	▂▃▇▇▂
log_nei_2008_pm10_sum_25000	0	1	6.07	2.010000e+00	0.00	5.10	6.37	7.52	9.880000e+00	▁▂▆▇▃
popdens_county	0	1	551.76	1.711510e+03	0.26	40.77	156.67	510.81	2.682191e+04	▇▁▁▁▁
popdens_zcta	0	1	1279.66	2.757490e+03	0.00	101.15	610.35	1382.52	3.041884e+04	▇▁▁▁▁
nohs	0	1	6.99	7.210000e+00	0.00	2.70	5.10	8.80	1.000000e+02	▇▁▁▁▁
somehs	0	1	10.17	6.200000e+00	0.00	5.90	9.40	13.90	7.220000e+01	▇▂▁▁▁
hs	0	1	30.32	1.140000e+01	0.00	23.80	30.75	36.10	1.000000e+02	▂▇▂▁▁
somecollege	0	1	21.58	8.600000e+00	0.00	17.50	21.30	24.70	1.000000e+02	▆▇▁▁▁
associate	0	1	7.13	4.010000e+00	0.00	4.90	7.10	8.80	7.140000e+01	▇▁▁▁▁
bachelor	0	1	14.90	9.710000e+00	0.00	8.80	12.95	19.22	1.000000e+02	▇▂▁▁▁
grad	0	1	8.91	8.650000e+00	0.00	3.90	6.70	11.00	1.000000e+02	▇▁▁▁▁
pov	0	1	14.95	1.133000e+01	0.00	6.50	12.10	21.22	6.590000e+01	▇▅▂▁▁
hs_orless	0	1	47.48	1.675000e+01	0.00	37.92	48.65	59.10	1.000000e+02	▁▃▇▃▁
urc2013	0	1	2.92	1.520000e+00	1.00	2.00	3.00	4.00	6.000000e+00	▇▅▃▂▁
urc2006	0	1	2.97	1.520000e+00	1.00	2.00	3.00	4.00	6.000000e+00	▇▅▃▂▁
aod	0	1	43.70	1.956000e+01	5.00	31.66	40.17	49.67	1.430000e+02	▃▇▁▁▁

Notice how there is a column called n_missing about the number of values that are missing. It looks like our data is very complete and we do not have any missing data. This is also indicated by the complete_rate variable, which shows the ratio of completeness, in our case all variables have a value of 1 indicating they are fully complete.

The n_unqiue column shows us the number of unique values for each of our columns. We can see that there are 49 states represented in the data, and we know that the data should be of the contiguous states. Let’s take a look to see which states are included:

# Scroll through the output!
pm %>% 
  distinct(state) %>%
  print(n = 1e3)

# A tibble: 49 x 1
   state               
   <chr>               
 1 Alabama             
 2 Arizona             
 3 Arkansas            
 4 California          
 5 Colorado            
 6 Connecticut         
 7 Delaware            
 8 District Of Columbia
 9 Florida             
10 Georgia             
11 Idaho               
12 Illinois            
13 Indiana             
14 Iowa                
15 Kansas              
16 Kentucky            
17 Louisiana           
18 Maine               
19 Maryland            
20 Massachusetts       
21 Michigan            
22 Minnesota           
23 Mississippi         
24 Missouri            
25 Montana             
26 Nebraska            
27 Nevada              
28 New Hampshire       
29 New Jersey          
30 New Mexico          
31 New York            
32 North Carolina      
33 North Dakota        
34 Ohio                
35 Oklahoma            
36 Oregon              
37 Pennsylvania        
38 Rhode Island        
39 South Carolina      
40 South Dakota        
41 Tennessee           
42 Texas               
43 Utah                
44 Vermont             
45 Virginia            
46 Washington          
47 West Virginia       
48 Wisconsin           
49 Wyoming             

Looks like “District of Columbia” is being included as a state. We can see that indeed Alaska and Hawaii are not included in the data.

Here is another method of looking at the data using the dfSummary() function of the summarytoolspackage. We need to copy and paste the output into the rmarkdown.

dfSummary(pm, plain.ascii = FALSE, style = "grid", 
          graph.magnif = 0.45,  tmp.img.dir = "tmp")

Dimensions: 876 x 50
Duplicates: 0

No	Variable	Stats / Values	Freqs (% of Valid)	Graph	Valid	Missing
1	id [factor]	1. 1003.001 2. 1027.0001 3. 1033.1002 4. 1049.1003 5. 1055.001 6. 1069.0003 7. 1073.0023 8. 1073.1005 9. 1073.1009 10. 1073.101 [ 866 others ]	1 ( 0.1%) 1 ( 0.1%) 1 ( 0.1%) 1 ( 0.1%) 1 ( 0.1%) 1 ( 0.1%) 1 ( 0.1%) 1 ( 0.1%) 1 ( 0.1%) 1 ( 0.1%) 866 (98.9%)		876 (100%)	0 (0%)
2	value [numeric]	Mean (sd) : 10.8 (2.6) min < med < max: 3 < 11.2 < 23.2 IQR (CV) : 3.1 (0.2)	875 distinct values		876 (100%)	0 (0%)
3	fips [factor]	1. 1003 2. 1027 3. 1033 4. 1049 5. 1055 6. 1069 7. 1073 8. 1089 9. 1097 10. 1101 [ 559 others ]	1 ( 0.1%) 1 ( 0.1%) 1 ( 0.1%) 1 ( 0.1%) 1 ( 0.1%) 1 ( 0.1%) 8 ( 0.9%) 1 ( 0.1%) 2 ( 0.2%) 1 ( 0.1%) 858 (98.0%)		876 (100%)	0 (0%)
4	lat [numeric]	Mean (sd) : 38.5 (4.6) min < med < max: 25.5 < 39.3 < 48.4 IQR (CV) : 6.6 (0.1)	876 distinct values		876 (100%)	0 (0%)
5	lon [numeric]	Mean (sd) : -91.7 (15) min < med < max: -124.2 < -87.5 < -68 IQR (CV) : 18.5 (-0.2)	876 distinct values		876 (100%)	0 (0%)
6	state [character]	1. California 2. Ohio 3. Illinois 4. Indiana 5. North Carolina 6. Pennsylvania 7. Michigan 8. Florida 9. Georgia 10. Texas [ 39 others ]	85 ( 9.7%) 44 ( 5.0%) 38 ( 4.3%) 36 ( 4.1%) 35 ( 4.0%) 32 ( 3.7%) 30 ( 3.4%) 29 ( 3.3%) 28 ( 3.2%) 27 ( 3.1%) 492 (56.2%)		876 (100%)	0 (0%)
7	county [character]	1. Jefferson 2. Cook 3. Hamilton 4. Lake 5. Los Angeles 6. Wayne 7. Washington 8. Cuyahoga 9. Jackson 10. Madison [ 461 others ]	18 ( 2.1%) 12 ( 1.4%) 11 ( 1.3%) 11 ( 1.3%) 10 ( 1.1%) 10 ( 1.1%) 9 ( 1.0%) 7 ( 0.8%) 7 ( 0.8%) 7 ( 0.8%) 774 (88.4%)		876 (100%)	0 (0%)
8	city [character]	1. Not in a city 2. New York 3. Cleveland 4. Baltimore 5. Chicago 6. Detroit 7. Milwaukee 8. New Haven 9. Philadelphia 10. Springfield [ 597 others ]	103 (11.8%) 9 ( 1.0%) 6 ( 0.7%) 5 ( 0.6%) 5 ( 0.6%) 5 ( 0.6%) 5 ( 0.6%) 5 ( 0.6%) 5 ( 0.6%) 5 ( 0.6%) 723 (82.5%)		876 (100%)	0 (0%)
9	CMAQ  | Me [numeric]	an (sd) : 8.4 (3)  | 60 min < med < max: 1.6 < 8.6 < 23.1 IQR (CV) : 3.7 (0.4)	1 distinct values |  | 87	6  | 0 (100%)	(0%)
10	zcta [factor]	1. 1022 2. 1103 3. 1201 4. 1608 5. 1832 6. 1840 7. 1863 8. 1904 9. 2113 10. 2119 [ 832 others ]	1 ( 0.1%) 2 ( 0.2%) 1 ( 0.1%) 2 ( 0.2%) 1 ( 0.1%) 1 ( 0.1%) 1 ( 0.1%) 1 ( 0.1%) 1 ( 0.1%) 1 ( 0.1%) 864 (98.6%)		876 (100%)	0 (0%)
11	zcta_area [numeric]	Mean (sd) : 183173481.9 (542598878.5) min < med < max: 15459 < 37653560.5 < 8164820625 IQR (CV) : 145836906.5 (3)	842 distinct values		876 (100%)	0 (0%)
12	zcta_pop [numeric]	Mean (sd) : 24227.6 (17772.2) min < med < max: 0 < 22014 < 95397 IQR (CV) : 25207.8 (0.7)	837 distinct values		876 (100%)	0 (0%)
13	imp_a500 [numeric]	Mean (sd) : 24.7 (19.3) min < med < max: 0 < 25.1 < 69.6 IQR (CV) : 36.5 (0.8)	816 distinct values		876 (100%)	0 (0%)
14	imp_a1000 [numeric]	Mean (sd) : 24.3 (18) min < med < max: 0 < 24.5 < 67.5 IQR (CV) : 33.3 (0.7)	860 distinct values		876 (100%)	0 (0%)
15	imp_a5000 [numeric]	Mean (sd) : 19.9 (14.7) min < med < max: 0.1 < 19.1 < 74.6 IQR (CV) : 23.3 (0.7)	870 distinct values		876 (100%)	0 (0%)
16	imp_a10000 [numeric]	Mean (sd) : 15.8 (13.8) min < med < max: 0.1 < 12.4 < 72.1 IQR (CV) : 19.6 (0.9)	870 distinct values		876 (100%)	0 (0%)
17	imp_a15000 [numeric]	Mean (sd) : 13.4 (13.1) min < med < max: 0.1 < 9.7 < 71.1 IQR (CV) : 17.3 (1)	870 distinct values		876 (100%)	0 (0%)
18	county_area [numeric]	Mean (sd) : 3768701992.1 (6212829553.6) min < med < max: 33703512 < 1690826566.5 < 51947229509 IQR (CV) : 1761655911.5 (1.6)	564 distinct values		876 (100%)	0 (0%)
19	county_pop [numeric]	Mean (sd) : 687298.4 (1293488.7) min < med < max: 783 < 280730.5 < 9818605 IQR (CV) : 642211 (1.9)	564 distinct values		876 (100%)	0 (0%)
20	log_dist_to_prisec [numeric]	Mean (sd) : 6.2 (1.4) min < med < max: -1.5 < 6.4 < 10.5 IQR (CV) : 1.7 (0.2)	870 distinct values		876 (100%)	0 (0%)
21	log_pri_length_5000 [numeric]	Mean (sd) : 9.8 (1.1) min < med < max: 8.5 < 10.1 < 12 IQR (CV) : 2.2 (0.1)	586 distinct values		876 (100%)	0 (0%)
22	log_pri_length_10000 [numeric]	Mean (sd) : 10.9 (1.1) min < med < max: 9.2 < 11.2 < 13 IQR (CV) : 2 (0.1)	687 distinct values		876 (100%)	0 (0%)
23	log_pri_length_15000 [numeric]	Mean (sd) : 11.5 (1.1) min < med < max: 9.6 < 11.7 < 13.6 IQR (CV) : 1.5 (0.1)	726 distinct values		876 (100%)	0 (0%)
24	log_pri_length_25000 [numeric]	Mean (sd) : 12.2 (1.1) min < med < max: 10.1 < 12.5 < 14.4 IQR (CV) : 1.4 (0.1)	787 distinct values		876 (100%)	0 (0%)
25	log_prisec_length_500 [numeric]	Mean (sd) : 7 (1) min < med < max: 6.2 < 6.2 < 9.4 IQR (CV) : 1.6 (0.1)	382 distinct values		876 (100%)	0 (0%)
26	log_prisec_length_1000 [numeric]	Mean (sd) : 8.6 (0.8) min < med < max: 7.6 < 8.7 < 10.5 IQR (CV) : 1.6 (0.1)	591 distinct values		876 (100%)	0 (0%)
27	log_prisec_length_5000 [numeric]	Mean (sd) : 11.3 (0.8) min < med < max: 8.5 < 11.4 < 12.8 IQR (CV) : 0.9 (0.1)	852 distinct values		876 (100%)	0 (0%)
28	log_prisec_length_10000 [numeric]	Mean (sd) : 12.4 (0.7) min < med < max: 9.2 < 12.5 < 13.8 IQR (CV) : 1 (0.1)	867 distinct values		876 (100%)	0 (0%)
29	log_prisec_length_15000 [numeric]	Mean (sd) : 13 (0.7) min < med < max: 9.6 < 13.1 < 14.4 IQR (CV) : 1 (0.1)	869 distinct values		876 (100%)	0 (0%)
30	log_prisec_length_25000 [numeric]	Mean (sd) : 13.8 (0.7) min < med < max: 10.1 < 13.9 < 15.2 IQR (CV) : 1 (0.1)	870 distinct values		876 (100%)	0 (0%)
31	log_nei_2008_pm25_sum_10000 [numeric]	Mean (sd) : 4 (2.4) min < med < max: 0 < 4.3 < 9.1 IQR (CV) : 3.5 (0.6)	828 distinct values		876 (100%)	0 (0%)
32	log_nei_2008_pm25_sum_15000 [numeric]	Mean (sd) : 4.7 (2.2) min < med < max: 0 < 5 < 9.4 IQR (CV) : 2.9 (0.5)	855 distinct values		876 (100%)	0 (0%)
33	log_nei_2008_pm25_sum_25000 [numeric]	Mean (sd) : 5.7 (2.1) min < med < max: 0 < 5.9 < 9.7 IQR (CV) : 2.6 (0.4)	860 distinct values		876 (100%)	0 (0%)
34	log_nei_2008_pm10_sum_10000 [numeric]	Mean (sd) : 4.3 (2.3) min < med < max: 0 < 4.6 < 9.3 IQR (CV) : 3.4 (0.5)	829 distinct values		876 (100%)	0 (0%)
35	log_nei_2008_pm10_sum_15000 [numeric]	Mean (sd) : 5.1 (2.2) min < med < max: 0 < 5.4 < 9.7 IQR (CV) : 2.8 (0.4)	855 distinct values		876 (100%)	0 (0%)
36	log_nei_2008_pm10_sum_25000 [numeric]	Mean (sd) : 6.1 (2) min < med < max: 0 < 6.4 < 9.9 IQR (CV) : 2.4 (0.3)	860 distinct values		876 (100%)	0 (0%)
37	popdens_county [numeric]	Mean (sd) : 551.8 (1711.5) min < med < max: 0.3 < 156.7 < 26821.9 IQR (CV) : 470 (3.1)	564 distinct values		876 (100%)	0 (0%)
38	popdens_zcta [numeric]	Mean (sd) : 1279.7 (2757.5) min < med < max: 0 < 610.3 < 30418.8 IQR (CV) : 1281.4 (2.2)	840 distinct values		876 (100%)	0 (0%)
39	nohs [numeric]	Mean (sd) : 7 (7.2) min < med < max: 0 < 5.1 < 100 IQR (CV) : 6.1 (1)	215 distinct values		876 (100%)	0 (0%)
40	somehs [numeric]	Mean (sd) : 10.2 (6.2) min < med < max: 0 < 9.4 < 72.2 IQR (CV) : 8 (0.6)	230 distinct values		876 (100%)	0 (0%)
41	hs [numeric]	Mean (sd) : 30.3 (11.4) min < med < max: 0 < 30.8 < 100 IQR (CV) : 12.3 (0.4)	347 distinct values		876 (100%)	0 (0%)
42	somecollege [numeric]	Mean (sd) : 21.6 (8.6) min < med < max: 0 < 21.3 < 100 IQR (CV) : 7.2 (0.4)	240 distinct values		876 (100%)	0 (0%)
43	associate [numeric]	Mean (sd) : 7.1 (4) min < med < max: 0 < 7.1 < 71.4 IQR (CV) : 3.9 (0.6)	157 distinct values		876 (100%)	0 (0%)
44	bachelor [numeric]	Mean (sd) : 14.9 (9.7) min < med < max: 0 < 12.9 < 100 IQR (CV) : 10.4 (0.7)	301 distinct values		876 (100%)	0 (0%)
45	grad [numeric]	Mean (sd) : 8.9 (8.6) min < med < max: 0 < 6.7 < 100 IQR (CV) : 7.1 (1)	245 distinct values		876 (100%)	0 (0%)
46	pov [numeric]	Mean (sd) : 15 (11.3) min < med < max: 0 < 12.1 < 65.9 IQR (CV) : 14.7 (0.8)	345 distinct values		876 (100%)	0 (0%)
47	hs_orless [numeric]	Mean (sd) : 47.5 (16.8) min < med < max: 0 < 48.7 < 100 IQR (CV) : 21.2 (0.4)	464 distinct values		876 (100%)	0 (0%)
48	urc2013 [numeric]	Mean (sd) : 2.9 (1.5) min < med < max: 1 < 3 < 6 IQR (CV) : 2 (0.5)	1 : 203 (23.2%) 2 : 163 (18.6%) 3 : 228 (26.0%) 4 : 123 (14.0%) 5 : 101 (11.5%) 6 : 58 ( 6.6%)		876 (100%)	0 (0%)
49	urc2006 [numeric]	Mean (sd) : 3 (1.5) min < med < max: 1 < 3 < 6 IQR (CV) : 2 (0.5)	1 : 195 (22.3%) 2 : 162 (18.5%) 3 : 221 (25.2%) 4 : 127 (14.5%) 5 : 115 (13.1%) 6 : 56 ( 6.4%)		876 (100%)	0 (0%)
50	aod [numeric]	Mean (sd) : 43.7 (19.6) min < med < max: 5 < 40.2 < 143 IQR (CV) : 18 (0.4)	581 distinct values		876 (100%)	0 (0%)

We can see that for many variables there are many low values as the distribution shows two peaks, one near zero and another with a higher value. This is true for the imp variables (measures of development), the nei variables (measures of emission sources) and the road density variables. We can also see that the range of some of the variables is very large, in particular the area and population related variables.

In prediction analyses, it is also useful to evaluate if any of the variables are correlated.

Intuitively we can expect some of our variables to be correlated.

We expect the development variables (imp) to be correlated with each other, we expect the road density variables to be correlated with each other, we expect the emission variables to be correlated with each other, and we also expect these variables to be correlated with one another and likely correlated with population density. We can get a nice visualization of correlation using the ggcorr() function and the ggpairs() function of the GGally package. to select our variables of interest we can use the select() function with the contains() function of the tidyr package.

First let’s look at the imp/development variables.

select(pm, contains("imp")) %>%
  ggcorr(palette = "RdBu", label = TRUE)

select(pm, contains("imp")) %>%
  ggpairs()

Indeed, we can see that imp_a1000 and imp_a500 are perfectly correlated, as well as imp_a10000, imp_a15000.

Now let’s take a look at the road density data:

select(pm, contains("pri")) %>%
  ggcorr(palette = "RdBu",  hjust = .85, size = 3,
       layout.exp=2, label = TRUE)

select(pm, contains("pri")) %>%
  ggpairs()

We can see that while some of the road density variables are highly correlated with one another (or anti-correlated), there arr some variables that are less correlated with one another.

Finally let’s look at the emission variables.

select(pm, contains("nei")) %>%
  ggcorr(palette = "RdBu",  hjust = .85, size = 3,
       layout.exp=2, label = TRUE)

select(pm, contains("nei")) %>%
  ggpairs()

We would also expect the population density data might correlate with some of these variables. Let’s take a look.

pm %>%
select(log_nei_2008_pm25_sum_10000, popdens_county, log_pri_length_10000, imp_a10000) %>%
  ggcorr(palette = "RdBu",  hjust = .85, size = 3,
       layout.exp=2, label = TRUE)

pm %>%
select(log_nei_2008_pm25_sum_10000, popdens_county, log_pri_length_10000, imp_a10000, county_pop) %>%
  ggpairs()

Interesting, so these variables don’t appear to be highly correlated, therefore we might need variables from each of the categories to predict our monitor PM_2.5 pollution values.

We seem to have some pretty extreme population values though, so let’s see what happens when we take the log value.

pm %>%
  mutate(log_popdens_county= log(popdens_county)) %>%
select(log_nei_2008_pm25_sum_10000, log_popdens_county, log_pri_length_10000, imp_a10000) %>%
  ggcorr(palette = "RdBu",  hjust = .85, size = 3,
       layout.exp=2, label = TRUE)

pm %>%
  mutate(log_popdens_county= log(popdens_county)) %>%
  mutate(log_pop_county = log(county_pop)) %>%
select(log_nei_2008_pm25_sum_10000, log_popdens_county, log_pri_length_10000, imp_a10000, log_pop_county) %>%
  ggpairs()

Indeed this increased the correlation, but variables from each of these categories may still prove to be useful for prediction.

Data Analysis

Now that we have a sense of what our data is like we can get started with data analysis.

The tidymodels ecosystem

To perform our analysis we will be using the tidymodels suite of packages. You may be familiar with the older packages caret or mlr which are also for machine learning and modeling but are not a part of the tidyverse. Max Kuhn describes tidymodels like this:

“Other packages, such as caret and mlr, help to solve the R model API issue. These packages do a lot of other things too: preprocessing, model tuning, resampling, feature selection, ensembling, and so on. In the tidyverse, we strive to make our packages modular and parsnip is designed only to solve the interface issue. It is not designed to be a drop-in replacement for caret. The tidymodels package collection, which includes parsnip, has other packages for many of these tasks, and they are designed to work together. We are working towards higher-level APIs that can replicate and extend what the current model packages can do.”

The major benefits of tidymodels

1. standardized workflow/format/notation across different types of algorithms
2. can easily modify preprocessing, algorithm choice, and hyper-parameter tuning making optimization easy

The machine learning process

The tidymodels ecosystem - an overview

There are many packages in the tidymodels ecosystem which assist with the various steps of the machine learning process:

This is the overall process:

There are two distinct goals of supervised machine learning:

1. Prediction
   
2. Classification

We will be performing a prediction analysis (which is also refered to as regression), which aims to predict continuous outcome variables given a number of predictors/explanatory variables/features/parameters, as we have already described.

Classification on the other hand aims to discern or predict group identity for a categorical outcome based on a number of predictors/explanatory variables/features/parameters.

The overall process is the same in either case.

Splitting the Data

The first step after data exploration in machine learning analysis is to split the data into training and testing datasets.

The training dataset will be used to build and tune our model. This is the data that the model “learns” on.

The testing set will be used to evaluate the performance of our model in a more generalizable way. What do we mean by “generalizable”?

Remember that our main goal is to use our model to be able to predict air pollution levels in areas where there are no gravimetric monitors. Therefore, if our model is super good at predicting air pollution with the data that we use to build it, it might not do the best job for the areas where there are few to no monitors. This would cause us to have really good prediction accuracy and we might assume that we were going to do a good job estimating air pollution any time we use our model, but in fact this would likely not be the case. This situation is what we call overfitting .

Overfitting happens when we end up modeling not only the major relationships in our data but also the noise within our data.

knitr::include_graphics("https://miro.medium.com/max/1110/1*tBErXYVvTw2jSUYK7thU2A.png")

[source]

If we get fairly good prediction with our testing set then we will know that our model can be applied to other data and will perform fairly well. We will discuss this more later.

We will not touch the testing set until we have completed optimizing our model with the training set. This will allow us to have a less biased evaluation of how well our model can do with other data besides the data used in the training set to build the model. Ideally you would also want a completely independent dataset to further test the performance of your model.

Here is a great description of the differences between testing and training datasets.

We will use the rsample package to perform this step.

Theinitial_split() function allows us to specify how we want to split our data. Typically data is split into 3/4 for training and 1/4 for testing.This is the default proportion and does not need to be specified. However you can change the proportion using the prop argument, which we will do that here for illustrative purposes. You can also specify a variable to stratify by with the strata argument. This is useful if you have imbalanced categorical variables and you would like to intentionally make sure that there are similar number of samples of the rarer categories in both the testing and training sets. Otherwise the split is performed randomly.

The strata argument causes the random sampling to be conducted within the stratification variable. The can help ensure that the number of data points in the training data is equivalent to the proportions in the original data set.

In the case with our dataset, perhaps we would like our training set to have similar proportions of monitors from each of the states as in the initial data. This might be useful if we want our model to be generalizable across all of the states.

We can see that indeed there are different proportions of monitors in each state by using the count() function of the dpyr package.

# Scroll through the output!
count(pm, state) %>%
  print(n = 1e3)

# A tibble: 49 x 2
   state                    n
   <chr>                <int>
 1 Alabama                 24
 2 Arizona                 17
 3 Arkansas                16
 4 California              85
 5 Colorado                15
 6 Connecticut             14
 7 Delaware                 7
 8 District Of Columbia     3
 9 Florida                 29
10 Georgia                 28
11 Idaho                    7
12 Illinois                38
13 Indiana                 36
14 Iowa                    20
15 Kansas                  10
16 Kentucky                22
17 Louisiana               17
18 Maine                    1
19 Maryland                15
20 Massachusetts           16
21 Michigan                30
22 Minnesota               17
23 Mississippi             12
24 Missouri                13
25 Montana                 16
26 Nebraska                 7
27 Nevada                   4
28 New Hampshire            7
29 New Jersey              23
30 New Mexico              10
31 New York                24
32 North Carolina          35
33 North Dakota             4
34 Ohio                    44
35 Oklahoma                10
36 Oregon                  17
37 Pennsylvania            32
38 Rhode Island             5
39 South Carolina          14
40 South Dakota             9
41 Tennessee                3
42 Texas                   27
43 Utah                    14
44 Vermont                  4
45 Virginia                20
46 Washington               8
47 West Virginia           14
48 Wisconsin               21
49 Wyoming                 12

If our dataset were large enough it might be nice then to stratify by state, but our data is unfortunately not large enough. We will show how one would do this though for illustrative purposes. This option is often more important for classification applications of machine learning than it is for prediction.

Since the split is performed randomly, it is a good idea to use the set.seed() base function to ensure that if your rerun your code that your split will be the same next time. We can see the number of monitors in our training, testing, and original data by typing in the name of our split object. The result will look like this: <training data sample number, testing data sample number, original sample number>

set.seed(1234)
pm_split <-rsample::initial_split(data = pm, prop = 2/3)
pm_split

<584/292/876>

# If stratifying:
# pm_split_strata <-rsample::initial_split(data = pm, prop = 2/3, strata = "state")

Importantly the initial_split function only determines what rows of our pm data frame should be assigned for training or testing, it does not actually split the data.

To extract the testing and training data we can use the training() and testing() functions also of the rsample package.

 train_pm <-rsample::training(pm_split)
 test_pm <-rsample::testing(pm_split)
 
# Scroll through the output!
count(train_pm, state)

# A tibble: 48 x 2
   state                    n
   <chr>                <int>
 1 Alabama                 18
 2 Arizona                 12
 3 Arkansas                14
 4 California              54
 5 Colorado                12
 6 Connecticut              8
 7 Delaware                 6
 8 District Of Columbia     2
 9 Florida                 18
10 Georgia                 17
# … with 38 more rows

count(test_pm, state)

# A tibble: 48 x 2
   state                    n
   <chr>                <int>
 1 Alabama                  6
 2 Arizona                  5
 3 Arkansas                 2
 4 California              31
 5 Colorado                 3
 6 Connecticut              6
 7 Delaware                 1
 8 District Of Columbia     1
 9 Florida                 11
10 Georgia                 11
# … with 38 more rows

Variable Role Assignment and Preprocessing

In tidymodels we will create a recipe, which is a standardized format for a sequence of steps for processing the data.

This can be very useful because it makes testing out different pre-processing steps or different algorithms with the same pre-processing very easy and reproducible.

Creating a recipe specifies how a dataframe of predictors should be created - it specifies what variables to be used and the preprocessing steps but it does not execute these steps or create the dataframe of predictors.

List the ingredients / specify the variables with the recipe() function

The first thing to do to create a recipe is to specify which variables we will be using as our outcome and predictors using the recipe() function. In terms of the metaphor of baking, we can think of this as listing our ingredients. The naming convention for recipe object names is *_rec or rec.

In our case recall that our value variable, which is the average annual gravimetric monitor PM_2.5 concentration in ug/m³. Our predictors are all the other variables except the monitor ID, which is an id variable.

The reason not to include this variable is because this variable includes the county number and a number designating which particular monitor the values came from of the monitors there are in that county. Since this number is arbitrary and the county information is also given in the data, and the fact that each monitor only has one value in the value variable, nothing is gained by including this variable and it may instead introduce noise. However, it is useful to keep this data to take a look at what is happening later. We will show you what to do in this case in just a bit.

The simplest recipe with no preprocessing steps, would be to simply list the outcome and predictor variables.

We can do so in two ways:

1. Using formula notation
   
2. Assigning roles to each variable

Let’s look at the first way using formula notation, which looks like this:

outcome(s) ~ predictor(s)

If in the case of multiple predictors or a multivariate situation with two outcomes, use a plus sign

outcome1 + outcome2 ~ predictor1 + predictor2

If we want to include all predictors we can use a period like so:

outcome_variable_name ~ .

Now with our data we will start by making a recipe for our training data. In the simplest case we might use all predictors like this:

simple_rec <-train_pm %>%
  recipes::recipe(value ~ .)

simple_rec

Data Recipe

Inputs:

      role #variables
   outcome          1
 predictor         49

However, to deal with the id variable we could use the update_role() function of the recipes package:

simple_rec <-train_pm %>%
  recipes::recipe(value ~ .) %>%
  recipes::update_role(id, new_role = "id variable")

simple_rec

Data Recipe

Inputs:

        role #variables
 id variable          1
     outcome          1
   predictor         48

We could also specify the outcome and predictors in the same way as the id variable. Please see here for examples of other roles for variables. The role can be actually be any value.

The order is important here, as we first make all variables predictors and then override this role for the outcome and id variable. We will use the everything() function of the dplyr package to start with all of the variables in train_pm.

simple_rec <-recipe(train_pm) %>%
    update_role(everything(), new_role = "predictor")%>%
    update_role(value, new_role = "outcome")%>%
    update_role(id, new_role = "id variable")

simple_rec

Data Recipe

Inputs:

        role #variables
 id variable          1
     outcome          1
   predictor         48

If we want to take a look at our formula from our recipe we can do use the formula() function of the stats package.

formula(simple_rec)

value ~ fips + lat + lon + state + county + city + CMAQ + zcta + 
    zcta_area + zcta_pop + imp_a500 + imp_a1000 + imp_a5000 + 
    imp_a10000 + imp_a15000 + county_area + county_pop + log_dist_to_prisec + 
    log_pri_length_5000 + log_pri_length_10000 + log_pri_length_15000 + 
    log_pri_length_25000 + log_prisec_length_500 + log_prisec_length_1000 + 
    log_prisec_length_5000 + log_prisec_length_10000 + log_prisec_length_15000 + 
    log_prisec_length_25000 + log_nei_2008_pm25_sum_10000 + log_nei_2008_pm25_sum_15000 + 
    log_nei_2008_pm25_sum_25000 + log_nei_2008_pm10_sum_10000 + 
    log_nei_2008_pm10_sum_15000 + log_nei_2008_pm10_sum_25000 + 
    popdens_county + popdens_zcta + nohs + somehs + hs + somecollege + 
    associate + bachelor + grad + pov + hs_orless + urc2013 + 
    urc2006 + aod
<environment: 0x7fb3b4252040>

We can also view our recipe in more detail using the base summary() function.

summary(simple_rec)

# A tibble: 50 x 4
   variable type    role        source  
   <chr>    <chr>   <chr>       <chr>   
 1 id       nominal id variable original
 2 value    numeric outcome     original
 3 fips     nominal predictor   original
 4 lat      numeric predictor   original
 5 lon      numeric predictor   original
 6 state    nominal predictor   original
 7 county   nominal predictor   original
 8 city     nominal predictor   original
 9 CMAQ     numeric predictor   original
10 zcta     nominal predictor   original
# … with 40 more rows

List the preprocessing steps using the step functions of the recipe package

The other thing the recipes package allows for is specifying pre-processing steps using a variety of step*() functions.

This link and this link show the many options for recipe step functions.

There are step functions for a variety of purposes:

1. Imputation – which means filling in missing values based on the existing data
2. Transformation – which means changing all values of a variable in the same way, typically to make it more normal or easier to interpret)
   
3. Discretization – which means converting continuous values into discrete or nominal values - binning for example to reduce the number of possible levels) (However this is generally not advisable!)
4. Encoding / Creating Dummy Variables – which means creating a numeric code for categorical variables More on Dummy Variables and one hot encoding
5. Data type conversions – which means changing from integer to factor or numeric to date etc.
6. Interaction term addition to the model – which means that we would be modeling for predictors that would influence the capacity of each other to predict the outcome
7. Normalization – which means centering and scaling the data to a similar range of values
8. Dimensionality Reduction/ Signal Extraction – which means mathematically obtaining a new smaller set of variables that capture the variation or signal in the original variables (ex. Principal Component Analysis and Independent Component Analysis)
9. Filtering – Filtering options for removing variables (ex. remove variables that are highly correlated to others or remove variables with very little variance and therefore likely little predictive capacity)
10. Row operations – which means performing functions on the values within the rows (ex. rearranging, filtering, imputing)
11. Checking functions – Sanity checks to look for missing values, to look at the variable classes etc.

All of the step functions look like step_* except for the check functions which look like check_*.

There are several ways to select what variables to apply steps to:
1) tidyselect methods: contains(), matches(), starts_with(), ends_with(), everything(), num_range()
2) based on the type: all_nominal(), all_numeric() , has_type() 3) based on the role: all_predictors(), all_outcomes(), has_role() 4) name - use the actual name of the variable/variables of interest

Let’s try adding some steps to our recipe.

We might consider log transforming our population and area variables (that aren’t densities) - let’s take a look at the range of these variables.

pm %>%
  select(matches("_pop|_area")) %>%
  map(range)

$zcta_area
[1]      15459 8164820625

$zcta_pop
[1]     0 95397

$county_area
[1]    33703512 51947229509

$county_pop
[1]     783 9818605

We can see that the range for each of these variables is quite large, we can log transform this data using the step_log() function of the recipes package.

We would also want to potentially one hot encode some of our categorical variables so that they can be used with certain algorithms. We can do this with the step_dummy() function and the one_hot = TRUE argument. Our fips variable includes a numeric code for state and county - and therefore is essentially a proxy for county. Since we already have county, we will just use it and keep the fips id as another ID variable.

We can remove the fips variable from the predictors using update_role() to make sure that the role is no longer "predictor". We can make the role anything we want actually, so we will keep it something identifiable.

We might also want to remove variables that appear to be redundant and are highly correlated with others, as we know from our exploratory data analysis that many of our variables are correlated with one another. We can do this using the step_corr() function.

It is important to add the steps to the recipe in an order that makes sense just like with a cooking recipe.

simple_rec %<>%
  #step_log(matches("_pop|_area")) %>%
  update_role("fips", new_role = "county id") %>%
  step_dummy(state, county, city, zcta) %>%
  step_corr(all_numeric(), - CMAQ, - aod)%>%
  step_nzv(all_numeric()) 
  #step_dummy(state, county, city, zcta)
#  step_dummy(state, county, city, zcta, one_hot = TRUE)
 # check_new_values(all_predictors()) %>%
  #check_range(all_predictors())

#can use step_rm() to remove predictors
  
simple_rec

Data Recipe

Inputs:

        role #variables
   county id          1
 id variable          1
     outcome          1
   predictor         47

Operations:

Dummy variables from state, county, city, zcta
Correlation filter on all_numeric, -, CMAQ, -, aod
Sparse, unbalanced variable filter on all_numeric

OPTIONAL: Running the preprocessing (to see it)

The next major function of the recipes package is prep().

This function updates the recipe object based on the training data. It estimates parameters (estimating the required quantities and statistics required by the steps for the variables) for preprocessing and updates the model terms, as some of the predictors may be removed, this allows the recipe to be ready to use on other datasets. It doesn’t necessarily actually execute the preprocessing itself, however we will specify in argument for it to do this so that we can take a look at the preprocessed data.

There are some important arguments to know about: 1) training - you must supply a training data set to estimate parameters for preprocessing operations (recipe steps) - this may already be included in your recipe - as is the case for us 2) fresh - if TRUE - will retrain and estimate parameters for any previous steps that were already prepped if you add more steps to the recipe 3) verbose - if TRUE shows the progress as the steps are evaluated and the size of the preprocessed training set 4) retain - if TRUE then the preprocessed training set will be saved within the recipe (as template). This is good if you are likely to add more steps and don’t want to rerun the prep() on the previous steps. However this can make the recipe size large. This is necessary if you want to actually look at the preprocessed data.

prepped_rec <- prep(simple_rec, verbose = TRUE, retain = TRUE )

oper 1 step dummy [training] 
oper 2 step corr [training] 
oper 3 step nzv [training] 
The retained training set is ~ 0.26 Mb  in memory.

names(prepped_rec)

[1] "var_info"       "term_info"      "steps"          "template"      
[5] "levels"         "retained"       "tr_info"        "orig_lvls"     
[9] "last_term_info"

There are also lots of useful things to checkout in the output of prep(). You can see: 1) the steps that were run
2) the variable info (var_info)
3) the model term_info 4) the new levels of the variables 5) the original levels of the variables orig_lvls
6) info about the training data set size and completeness (tr_info)

Note: You may see the prep.recipe() function in material that you read about the recipes package. This is referring to the prep() function of the recipes package.

Extracting the preprocessed training data

Since we retained our preprocessed training data, we can take a look at it like by using the juice() function of the recipes package like this:

# Scroll therough the output!
prepped_train<- juice(prepped_rec)
glimpse(prepped_train)

Observations: 584
Variables: 36
$ id                          <fct> 1003.001, 1027.0001, 1033.1002, 1055…
$ value                       <dbl> 9.597647, 10.800000, 11.212174, 12.3…
$ fips                        <fct> 1003, 1027, 1033, 1055, 1069, 1073, …
$ lat                         <dbl> 30.49800, 33.28126, 34.75878, 33.993…
$ lon                         <dbl> -87.88141, -85.80218, -87.65056, -85…
$ CMAQ                        <dbl> 8.098836, 9.766208, 9.402679, 9.2417…
$ zcta_area                   <dbl> 190980522, 374132430, 16716984, 1540…
$ zcta_pop                    <dbl> 27829, 5103, 9042, 20045, 30217, 901…
$ imp_a500                    <dbl> 0.01730104, 1.96972318, 19.17301038,…
$ imp_a15000                  <dbl> 1.4386207, 0.3359198, 5.2472094, 5.1…
$ county_area                 <dbl> 4117521611, 1564252280, 1534877333, …
$ county_pop                  <dbl> 182265, 13932, 54428, 104430, 101547…
$ log_dist_to_prisec          <dbl> 4.648181, 7.219907, 5.760131, 5.2614…
$ log_pri_length_5000         <dbl> 8.517193, 8.517193, 8.517193, 9.0665…
$ log_pri_length_25000        <dbl> 11.32735, 10.12663, 10.15769, 12.013…
$ log_prisec_length_500       <dbl> 7.295356, 6.214608, 8.611945, 8.7406…
$ log_prisec_length_1000      <dbl> 8.195119, 7.600902, 9.735569, 9.6278…
$ log_prisec_length_5000      <dbl> 10.815042, 10.170878, 11.770407, 11.…
$ log_prisec_length_10000     <dbl> 11.88680, 11.40554, 12.84066, 12.768…
$ log_nei_2008_pm10_sum_15000 <dbl> 2.26783411, 3.31111648, 6.70127741, …
$ log_nei_2008_pm10_sum_25000 <dbl> 5.628728, 3.311116, 7.148858, 4.6783…
$ popdens_county              <dbl> 44.265706, 8.906492, 35.460814, 75.3…
$ popdens_zcta                <dbl> 145.716431, 13.639555, 540.887040, 1…
$ nohs                        <dbl> 3.3, 11.6, 7.3, 4.3, 5.8, 7.1, 2.7, …
$ somehs                      <dbl> 4.9, 19.1, 15.8, 13.3, 11.6, 17.1, 6…
$ hs                          <dbl> 25.1, 33.9, 30.6, 27.8, 29.8, 37.2, …
$ somecollege                 <dbl> 19.7, 18.8, 20.9, 29.2, 21.4, 23.5, …
$ associate                   <dbl> 8.2, 8.0, 7.6, 10.1, 7.9, 7.3, 8.0, …
$ bachelor                    <dbl> 25.3, 5.5, 12.7, 10.0, 13.7, 5.9, 17…
$ grad                        <dbl> 13.5, 3.1, 5.1, 5.4, 9.8, 2.0, 8.7, …
$ pov                         <dbl> 6.1, 19.5, 19.0, 8.8, 15.6, 25.5, 7.…
$ hs_orless                   <dbl> 33.3, 64.6, 53.7, 45.4, 47.2, 61.4, …
$ urc2013                     <dbl> 4, 6, 4, 4, 4, 1, 1, 1, 1, 1, 2, 3, …
$ aod                         <dbl> 37.36364, 34.81818, 36.00000, 43.416…
$ state_California            <dbl> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, …
$ city_Not.in.a.city          <dbl> 0, 0, 0, 0, 0, 0, 1, 1, 0, 0, 1, 0, …

For easy comparison sake - here is our original data: #### {.scrollable }

# Scroll therough the output!
glimpse(pm)

Observations: 876
Variables: 50
$ id                          <fct> 1003.001, 1027.0001, 1033.1002, 1049…
$ value                       <dbl> 9.597647, 10.800000, 11.212174, 11.6…
$ fips                        <fct> 1003, 1027, 1033, 1049, 1055, 1069, …
$ lat                         <dbl> 30.49800, 33.28126, 34.75878, 34.287…
$ lon                         <dbl> -87.88141, -85.80218, -87.65056, -85…
$ state                       <chr> "Alabama", "Alabama", "Alabama", "Al…
$ county                      <chr> "Baldwin", "Clay", "Colbert", "DeKal…
$ city                        <chr> "Fairhope", "Ashland", "Muscle Shoal…
$ CMAQ                        <dbl> 8.098836, 9.766208, 9.402679, 8.5347…
$ zcta                        <fct> 36532, 36251, 35660, 35962, 35901, 3…
$ zcta_area                   <dbl> 190980522, 374132430, 16716984, 2038…
$ zcta_pop                    <dbl> 27829, 5103, 9042, 8300, 20045, 3021…
$ imp_a500                    <dbl> 0.01730104, 1.96972318, 19.17301038,…
$ imp_a1000                   <dbl> 1.4096021, 0.8531574, 11.1448962, 3.…
$ imp_a5000                   <dbl> 3.3360118, 0.9851479, 15.1786154, 1.…
$ imp_a10000                  <dbl> 1.9879187, 0.5208189, 9.7253870, 1.0…
$ imp_a15000                  <dbl> 1.4386207, 0.3359198, 5.2472094, 0.9…
$ county_area                 <dbl> 4117521611, 1564252280, 1534877333, …
$ county_pop                  <dbl> 182265, 13932, 54428, 71109, 104430,…
$ log_dist_to_prisec          <dbl> 4.648181, 7.219907, 5.760131, 3.7214…
$ log_pri_length_5000         <dbl> 8.517193, 8.517193, 8.517193, 8.5171…
$ log_pri_length_10000        <dbl> 9.210340, 9.210340, 9.274303, 10.409…
$ log_pri_length_15000        <dbl> 9.630228, 9.615805, 9.658899, 11.173…
$ log_pri_length_25000        <dbl> 11.32735, 10.12663, 10.15769, 11.909…
$ log_prisec_length_500       <dbl> 7.295356, 6.214608, 8.611945, 7.3101…
$ log_prisec_length_1000      <dbl> 8.195119, 7.600902, 9.735569, 8.5858…
$ log_prisec_length_5000      <dbl> 10.815042, 10.170878, 11.770407, 10.…
$ log_prisec_length_10000     <dbl> 11.88680, 11.40554, 12.84066, 11.508…
$ log_prisec_length_15000     <dbl> 12.205723, 12.042963, 13.282656, 12.…
$ log_prisec_length_25000     <dbl> 13.41395, 12.79980, 13.79973, 13.559…
$ log_nei_2008_pm25_sum_10000 <dbl> 0.318035438, 3.218632928, 6.57312730…
$ log_nei_2008_pm25_sum_15000 <dbl> 1.967358961, 3.218632928, 6.58191745…
$ log_nei_2008_pm25_sum_25000 <dbl> 5.067308, 3.218633, 6.875900, 4.8876…
$ log_nei_2008_pm10_sum_10000 <dbl> 1.35588511, 3.31111648, 6.69187313, …
$ log_nei_2008_pm10_sum_15000 <dbl> 2.26783411, 3.31111648, 6.70127741, …
$ log_nei_2008_pm10_sum_25000 <dbl> 5.628728, 3.311116, 7.148858, 5.1719…
$ popdens_county              <dbl> 44.265706, 8.906492, 35.460814, 35.3…
$ popdens_zcta                <dbl> 145.716431, 13.639555, 540.887040, 4…
$ nohs                        <dbl> 3.3, 11.6, 7.3, 14.3, 4.3, 5.8, 7.1,…
$ somehs                      <dbl> 4.9, 19.1, 15.8, 16.7, 13.3, 11.6, 1…
$ hs                          <dbl> 25.1, 33.9, 30.6, 35.0, 27.8, 29.8, …
$ somecollege                 <dbl> 19.7, 18.8, 20.9, 14.9, 29.2, 21.4, …
$ associate                   <dbl> 8.2, 8.0, 7.6, 5.5, 10.1, 7.9, 7.3, …
$ bachelor                    <dbl> 25.3, 5.5, 12.7, 7.9, 10.0, 13.7, 5.…
$ grad                        <dbl> 13.5, 3.1, 5.1, 5.8, 5.4, 9.8, 2.0, …
$ pov                         <dbl> 6.1, 19.5, 19.0, 13.8, 8.8, 15.6, 25…
$ hs_orless                   <dbl> 33.3, 64.6, 53.7, 66.0, 45.4, 47.2, …
$ urc2013                     <dbl> 4, 6, 4, 6, 4, 4, 1, 1, 1, 1, 1, 1, …
$ urc2006                     <dbl> 5, 6, 4, 5, 4, 4, 1, 1, 1, 1, 1, 1, …
$ aod                         <dbl> 37.36364, 34.81818, 36.00000, 33.083…

Notice how we only have 36 variables now instead of 50! Two of these are our ID variables (fips and the actual monitor ID (id)) and one is our outcome (value). Thus we only have 33 predictors now. We can also see that variables that we no longer have any categorical variables. Variables like state are gone and only state_California remains as it was the only state identity to have nonzero variance. We can see that California had the largest number of monitors compared to the other states. We can also see that there were more monitors listed as "Not in a city" than any city.

pm %>% count(state)

# A tibble: 49 x 2
   state                    n
   <chr>                <int>
 1 Alabama                 24
 2 Arizona                 17
 3 Arkansas                16
 4 California              85
 5 Colorado                15
 6 Connecticut             14
 7 Delaware                 7
 8 District Of Columbia     3
 9 Florida                 29
10 Georgia                 28
# … with 39 more rows

pm %>% count(city)

# A tibble: 607 x 2
   city            n
   <chr>       <int>
 1 Aberdeen        1
 2 Akron           2
 3 Albany          3
 4 Albuquerque     2
 5 Alexandria      1
 6 Allen Park      1
 7 Altamont        1
 8 Alton           1
 9 Amarillo        1
10 Anadarko        1
# … with 597 more rows

Note: Recall that you must specify retain = TRUE argument of the prep() function to use juice().

Extracting the preprocessed testing data

Later on if you want to look at the preprocessed testing data you would use the bake() function of the recipes package like this:

However you would want to leave your testing data alone at this point.

# Scroll therough the output!
baked_rec <- recipes::bake(prepped_rec, new_data = test_pm)
glimpse(baked_rec)

Observations: 292
Variables: 36
$ id                          <fct> 1049.1003, 1073.101, 1073.2006, 1089…
$ value                       <dbl> 11.659091, 13.114545, 12.228125, 12.…
$ fips                        <fct> 1049, 1073, 1073, 1089, 1103, 1121, …
$ lat                         <dbl> 34.28763, 33.54528, 33.38639, 34.687…
$ lon                         <dbl> -85.96830, -86.54917, -86.81667, -86…
$ CMAQ                        <dbl> 8.534772, 9.303766, 10.235612, 9.343…
$ zcta_area                   <dbl> 203836235, 148994881, 56063756, 4696…
$ zcta_pop                    <dbl> 8300, 14212, 32390, 21297, 30545, 77…
$ imp_a500                    <dbl> 5.78200692, 0.06055363, 42.42820069,…
$ imp_a15000                  <dbl> 0.9730444, 2.9956557, 12.7487614, 10…
$ county_area                 <dbl> 2012662359, 2878192209, 2878192209, …
$ county_pop                  <dbl> 71109, 658466, 658466, 334811, 11949…
$ log_dist_to_prisec          <dbl> 3.721489, 7.301545, 4.721755, 4.6595…
$ log_pri_length_5000         <dbl> 8.517193, 9.683336, 10.737240, 8.517…
$ log_pri_length_25000        <dbl> 11.90959, 12.53777, 12.99669, 11.473…
$ log_prisec_length_500       <dbl> 7.310155, 6.214608, 7.528913, 8.7605…
$ log_prisec_length_1000      <dbl> 8.585843, 7.600902, 9.342290, 9.5431…
$ log_prisec_length_5000      <dbl> 10.214200, 11.262645, 11.713190, 11.…
$ log_prisec_length_10000     <dbl> 11.50894, 12.14101, 12.53899, 12.684…
$ log_nei_2008_pm10_sum_15000 <dbl> 3.3500444, 6.6241114, 5.8268686, 3.8…
$ log_nei_2008_pm10_sum_25000 <dbl> 5.1719202, 7.5490587, 8.8205542, 5.2…
$ popdens_county              <dbl> 35.330814, 228.777633, 228.777633, 1…
$ popdens_zcta                <dbl> 40.718962, 95.385827, 577.735106, 45…
$ nohs                        <dbl> 14.3, 7.2, 0.8, 1.2, 4.8, 16.7, 19.1…
$ somehs                      <dbl> 16.7, 12.2, 2.6, 3.1, 7.8, 33.3, 15.…
$ hs                          <dbl> 35.0, 32.2, 12.9, 15.1, 28.7, 37.5, …
$ somecollege                 <dbl> 14.9, 19.0, 17.9, 20.5, 25.0, 12.5, …
$ associate                   <dbl> 5.5, 6.8, 5.2, 6.5, 7.5, 0.0, 6.0, 8…
$ bachelor                    <dbl> 7.9, 14.8, 35.5, 30.4, 18.2, 0.0, 10…
$ grad                        <dbl> 5.8, 7.7, 25.2, 23.3, 8.0, 0.0, 4.1,…
$ pov                         <dbl> 13.8, 10.5, 2.1, 5.2, 8.3, 18.8, 21.…
$ hs_orless                   <dbl> 66.0, 51.6, 16.3, 19.4, 41.3, 87.5, …
$ urc2013                     <dbl> 6, 1, 1, 3, 4, 5, 1, 2, 5, 4, 4, 6, …
$ aod                         <dbl> 33.08333, 42.45455, 44.25000, 42.416…
$ state_California            <dbl> 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, …
$ city_Not.in.a.city          <dbl> NA, NA, NA, NA, NA, NA, 0, NA, NA, N…

bake() takes a trained recipe and applies the operations to a data set to create a design matrix. for example: it applies the centering to new data sets using these means used to create the recipe

Note: if you use the skip option for some of the preprocessing steps, be careful. juice() will show all of the results ignoring skip = TRUE. bake() will not necessarily conduct these steps on the new data.

Specifying the Model

So far we have used rsample to split the data and recipes to assign variable and to specify and prep our preprocessing (as well as to optionally extract the preprocessed data).

We will now use the parsnip package (which is similar to the previous caret package - and hence why it is named after the vegetable) to specify our model.

There are four aspects to define about our model:
1) the type of model (using specific funtions in parsnip like rand_forest(), logistic_reg() etc.)
2) the mode of learning - classification or regression (using the set_mode() function)
3) the package or engine that we will use to implement the type of model selected (using the set_engine() function)
4) any arguments necessary for the model/package selected (using the set_args()function - for example the mtry = argument for random forest which is the number of variables to be used as options for splitting at each tree node)

We are going to start our analysis with a linear regression but we will demonstrate how we can try different models.

The first thing we do is define what type of model we would like to use. See here for modeling [options]in parsnip.

PM_model <- parsnip::linear_reg() #PM for particulate mater
PM_model

Linear Regression Model Specification (regression)

OK. So far all we have told parsnip is we want to use a linear regression… Let’s tell parsnip more about what we want.

We would like to use the ordinary least squares method to fit our linear regression. So we will tell parsnip that we want to use the lm package to implement our linear regression (there are many options actually- such as rstan glmnet, keras, and sparklyr). We will do so by using the set_engine() function of the parsnip package.

lm_PM_model <- 
  PM_model  %>%
  parsnip::set_engine("lm")

lm_PM_model

Linear Regression Model Specification (regression)

Computational engine: lm 

In some cases some packages can do either classification or prediction, so it is a good idea to specify which mode you intend to perform. You can do this with the set_mode() function of the parsnip package, by using either set_mode("classification") or set_mode("regression").

lm_PM_model <- 
  PM_model  %>%
  parsnip::set_engine("lm") %>%
  set_mode("regression")

lm_PM_model

Linear Regression Model Specification (regression)

Computational engine: lm 

Fitting the Model with workflows and parsnip

To fit our model we could use parsnip and then assess our fit using the yardstick package.

However a newer package called workflows allows us to keep track of both our preprocessing steps and our model specification. It also allows us to implement fancier optimizations in an automated way and it is currently being developed to also handle post-processing operations, so it is good to learn about it!

So we will now create a workflow with the recipe (our preprocessing specifications) that we made and the model that we just specified.

First we use the workflow() function of the workflows package to create a workflow.

Then we add our recipe with the add_recipe() function and we add our model with the add_model() function of the workflows package.

Note: We do not need to actually prep our recipe before using workflows!

PM_wflow <-workflows::workflow() %>%
           workflows::add_recipe(simple_rec) %>%
           workflows::add_model(lm_PM_model)
PM_wflow

══ Workflow ═════════════════════════════════════════════════════════════════════════════════
Preprocessor: Recipe
Model: linear_reg()

── Preprocessor ─────────────────────────────────────────────────────────────────────────────
3 Recipe Steps

● step_dummy()
● step_corr()
● step_nzv()

── Model ────────────────────────────────────────────────────────────────────────────────────
Linear Regression Model Specification (regression)

Computational engine: lm 

Ah, nice. Notice how it tells us about both our preprocessing steps and our model specifications.

Now we can prepare the recipe (estimate the parameters) and fit the model to our training data all at once. Printing the output we can see the coefficients of the model.

PM_wflow_fit <- parsnip::fit(PM_wflow, data = train_pm)
PM_wflow_fit

══ Workflow [trained] ═══════════════════════════════════════════════════════════════════════
Preprocessor: Recipe
Model: linear_reg()

── Preprocessor ─────────────────────────────────────────────────────────────────────────────
3 Recipe Steps

● step_dummy()
● step_corr()
● step_nzv()

── Model ────────────────────────────────────────────────────────────────────────────────────

Call:
stats::lm(formula = formula, data = data)

Coefficients:
                (Intercept)                          lat  
                  2.221e+02                    3.773e-02  
                        lon                         CMAQ  
                  3.023e-02                    2.896e-01  
                  zcta_area                     zcta_pop  
                  3.592e-10                    7.988e-06  
                   imp_a500                   imp_a15000  
                  6.543e-03                   -1.252e-03  
                county_area                   county_pop  
                 -2.241e-11                   -2.052e-07  
         log_dist_to_prisec          log_pri_length_5000  
                  4.182e-02                   -2.207e-01  
       log_pri_length_25000        log_prisec_length_500  
                  9.277e-02                    2.651e-01  
     log_prisec_length_1000       log_prisec_length_5000  
                 -1.654e-02                    4.451e-01  
    log_prisec_length_10000  log_nei_2008_pm10_sum_15000  
                  1.510e-01                    1.029e-01  
log_nei_2008_pm10_sum_25000               popdens_county  
                  6.448e-02                   -3.905e-05  
               popdens_zcta                         nohs  
                 -2.098e-05                   -2.195e+00  
                     somehs                           hs  
                 -2.232e+00                   -2.235e+00  
                somecollege                    associate  
                 -2.237e+00                   -2.237e+00  
                   bachelor                         grad  
                 -2.239e+00                   -2.248e+00  
                        pov                    hs_orless  
                  5.400e-03                           NA  
                    urc2013                          aod  
                  1.848e-01                    2.521e-02  
           state_California           city_Not.in.a.city  
                  3.509e+00                    4.137e-01  

Otherwise we could have done this without the workflows package. Notice here we will used the prepped training data as opposed to the raw training data that we used with the workflow we created with workflows.

PM_fit <- lm_PM_model %>% 
  parsnip::fit(value ~., data =prepped_train)

Looking at model fit with broom

The broom package allows for an easy/tidy way to look at the fitted model:

tidy() grabs the coefficients from the model
glance() summarizes the model fit
augment() gives a 150 row observation level summary

These broom functions currently only work with parsnip objects not raw workflows objects. To use these functions with workflows we need to first use the pull_workflow_fit() function.

broom::tidy(PM_fit)

# A tibble: 584 x 5
   term        estimate std.error statistic p.value
   <chr>          <dbl>     <dbl>     <dbl>   <dbl>
 1 (Intercept)    9.60        NaN       NaN     NaN
 2 id1027.0001    1.20        NaN       NaN     NaN
 3 id1033.1002    1.61        NaN       NaN     NaN
 4 id1055.001     2.78        NaN       NaN     NaN
 5 id1069.0003    0.911       NaN       NaN     NaN
 6 id1073.0023    5.99        NaN       NaN     NaN
 7 id1073.1005    2.80        NaN       NaN     NaN
 8 id1073.1009    1.51        NaN       NaN     NaN
 9 id1073.2003    4.95        NaN       NaN     NaN
10 id1073.5002    2.35        NaN       NaN     NaN
# … with 574 more rows

broom::glance(PM_fit$fit)

# A tibble: 1 x 11
  r.squared adj.r.squared sigma statistic p.value    df logLik   AIC   BIC
      <dbl>         <dbl> <dbl>     <dbl>   <dbl> <int>  <dbl> <dbl> <dbl>
1         1           NaN   NaN       NaN     NaN   584    Inf  -Inf  -Inf
# … with 2 more variables: deviance <dbl>, df.residual <int>

broom::augment(PM_fit$fit)

# A tibble: 584 x 41
   value id    fips    lat   lon  CMAQ zcta_area zcta_pop imp_a500
   <dbl> <fct> <fct> <dbl> <dbl> <dbl>     <dbl>    <dbl>    <dbl>
 1  9.60 1003… 1003   30.5 -87.9  8.10 190980522    27829   0.0173
 2 10.8  1027… 1027   33.3 -85.8  9.77 374132430     5103   1.97  
 3 11.2  1033… 1033   34.8 -87.7  9.40  16716984     9042  19.2   
 4 12.4  1055… 1055   34.0 -86.0  9.24 154069359    20045  16.5   
 5 10.5  1069… 1069   31.2 -85.4  9.12 162685124    30217  19.1   
 6 15.6  1073… 1073   33.6 -86.8 10.2   26929603     9010  41.8   
 7 12.4  1073… 1073   33.3 -87.0 10.2  166239542    16140   1.70  
 8 11.1  1073… 1073   33.5 -87.3  8.16 385566685     3699   0     
 9 14.6  1073… 1073   33.5 -86.9 10.2   10636977    11458  43.6   
10 12.0  1073… 1073   33.7 -86.7  9.30 150661846    21725   1.48  
# … with 574 more rows, and 32 more variables: imp_a15000 <dbl>,
#   county_area <dbl>, county_pop <dbl>, log_dist_to_prisec <dbl>,
#   log_pri_length_5000 <dbl>, log_pri_length_25000 <dbl>,
#   log_prisec_length_500 <dbl>, log_prisec_length_1000 <dbl>,
#   log_prisec_length_5000 <dbl>, log_prisec_length_10000 <dbl>,
#   log_nei_2008_pm10_sum_15000 <dbl>, log_nei_2008_pm10_sum_25000 <dbl>,
#   popdens_county <dbl>, popdens_zcta <dbl>, nohs <dbl>, somehs <dbl>,
#   hs <dbl>, somecollege <dbl>, associate <dbl>, bachelor <dbl>,
#   grad <dbl>, pov <dbl>, hs_orless <dbl>, urc2013 <dbl>, aod <dbl>,
#   state_California <dbl>, city_Not.in.a.city <dbl>, .fitted <dbl>,
#   .se.fit <dbl>, .resid <dbl>, .hat <dbl>, .sigma <dbl>

PM_wflow_fit %>% 
  pull_workflow_fit() %>% 
  tidy()

# A tibble: 33 x 5
   term         estimate std.error statistic  p.value
   <chr>           <dbl>     <dbl>     <dbl>    <dbl>
 1 (Intercept)  2.22e+ 2  1.20e+ 2     1.85  6.51e- 2
 2 lat          3.77e- 2  2.45e- 2     1.54  1.24e- 1
 3 lon          3.02e- 2  9.31e- 3     3.25  1.23e- 3
 4 CMAQ         2.90e- 1  4.29e- 2     6.75  3.66e-11
 5 zcta_area    3.59e-10  3.04e-10     1.18  2.38e- 1
 6 zcta_pop     7.99e- 6  5.55e- 6     1.44  1.50e- 1
 7 imp_a500     6.54e- 3  7.49e- 3     0.874 3.82e- 1
 8 imp_a15000  -1.25e- 3  1.19e- 2    -0.105 9.16e- 1
 9 county_area -2.24e-11  1.63e-11    -1.38  1.69e- 1
10 county_pop  -2.05e- 7  9.31e- 8    -2.20  2.79e- 2
# … with 23 more rows

OK, so we have fit our model on our training data, which means we have created a model to predict values of air pollution based on the predictors that we have included. Yay!

At this point we could take a look at the accuracy of our model performance, but we will only have one reference point: our testing dataset. And we haven’t done any tuning of our model or cross validation… so generally speaking you should not do this.

However if you were short on time you could continue like this.

need tune_*(), fit_resamples() or last_fit() to get any assessment of fit.

We could stop here and use the yardstick package to evaluate performance. First we would want to fit the model with hmmm not sure if I will do this or just skip and use tune even if we dont have any tuning??

Using parsnip we need to use the baked data testing data… or not???

# lm_fit <-lm_PM_model %>%
#   parsnip::fit(value ~.,data = juiced_rec)
#yardstick::metrics(lm_fit, truth, predicted)

# values_pred <- 
#   predict(PM_wflow_fit, baked_rec) %>% 
#   bind_cols(baked_rec %>% select(value, fips)) 
# values_pred


values_pred <- 
  predict(PM_wflow_fit, test_pm) %>% 
  bind_cols(test_pm %>% select(value, fips)) 
values_pred

# A tibble: 292 x 3
   .pred value fips 
   <dbl> <dbl> <fct>
 1 NA    11.7  1049 
 2 NA    13.1  1073 
 3 NA    12.2  1073 
 4 NA    12.2  1089 
 5 NA    11.4  1103 
 6 NA    12.2  1121 
 7  9.52 10.9  4013 
 8 NA    10.6  4021 
 9 NA    14.1  4023 
10 NA     5.83 4025 
# … with 282 more rows

#With Tune package:
#overallfit <-tune::last_fit(PM_wflow, pm_split)
#count(values_pred, .pred)

Say we were done optimizing our parameters we could then use the last_fit() function of the workflows package.

#overallfit <-tune::last_fit(PM_wflow, pm_split)
 # or
#overallfit <-PM_wflow %>%
#  tune::last_fit(pm_split)

##overallfit

We could check out test performance using the collect_metrics() function of the tune package.

model performance :https://medium.com/@limavallantin/metrics-to-measure-machine-learning-model-performance-e8c963665476

#test_performance <- overallfit  %>%tune::collect_metrics()
#test_performance

Here you can see the predictions for the test set (the 292 rows with predicitions out of the 876 original monitor values) also using the tune package with the collect_predictions() function.

#test_predictions <- overallfit  %>%tune::collect_predictions()
#print(test_predictions, n=1e3)

However we would really want to tune parameters and use cross validation for this.

yardstick can’t talk directly to workflows… need tune for that…

Cross validation sample splitting

We will use the rsample package again in order to further implement what are called cross validation techniques. This is also called resampling or repartioning. Note: we are not actually getting new samples from the underlying distribution so the term resampling is a bit of a misnomer.

Cross validation splits our training data into multiple training data sets to allow for an assessment of the accuracy of the model.

Here is a visualization of the concept for cross validation/resampling/repartitioning from Max Kuhn:

Technically creating our testing and training set out of our original training data is sometimes considered a form of cross validation called the holdout method. As we just learned this can give us a better sense of the accuracy of our data in a more generalizable way.

However, we can do a better job of optimizing our model for accuracy if we also perform another type of cross validation on the newly defined training set that we just created. There are many cross validation methods and most can be easily implemented using rsamples package. We will use a very popular method called either k-fold or v-fold cross validation.

This method involves essentially preforming the hold out method iteratively with the training data.

First the training set is divided into k or v equally sized smaller pieces.

Then the model is trained on the model on k-1 or v-1 subsets of the data iteratively (removing a different v or k untill all possible k-1 or v-1 sets have been evaluated) to get a sense of the performance of the model. This is really useful for fine tuning specific aspects of the model in a process called model tuning.

Here is a visualization of how the folds are created:

Note: People typically ignore spatial dependence with cross validation of air pollution monitoring data in the air pollution field, so we will do the same. However, it might make sense to leave out blocks of monitors rather than random individual monitors to help account for some spatial dependence.

The vfold_cv() function of the rsample package can be used to parse the training data into folds for k-fold/v-fold cross validation.

The v argument specifies the number of folds to create. The repeats argument specifies if any samples should be repeated across folds - defualt is FALSE The strata argument specifies a variable to stratify samples across folds (just like in initial_split()).

Again because these are created at random, we need to use the base set.seed() function in order to obtain the same results each time we knit this document.

set.seed(1234)

vfold_pm <-rsample::vfold_cv(data = train_pm, v = 10 )

vfold_pm

#  10-fold cross-validation 
# A tibble: 10 x 2
   splits           id    
   <named list>     <chr> 
 1 <split [525/59]> Fold01
 2 <split [525/59]> Fold02
 3 <split [525/59]> Fold03
 4 <split [525/59]> Fold04
 5 <split [526/58]> Fold05
 6 <split [526/58]> Fold06
 7 <split [526/58]> Fold07
 8 <split [526/58]> Fold08
 9 <split [526/58]> Fold09
10 <split [526/58]> Fold10

vfold_pm$splits$`1`

<525/59/584>

vfold_pm$splits$`2`

<525/59/584>

Once the folds are created they can be used to evaluate peformance by fitting the model to each of the resamples that we created:

We can fit the model to our cross validation folds using the fit_resamples() function of the tune package, by specifying our workflow object and the cross validation fold object we just created. See here for more information.

control <- control_resamples(save_pred = TRUE)
resample_fit <-tune::fit_resamples(PM_wflow, vfold_pm)

We can now take a look at various metrics of performance based on the fit of our 10 cross validation “resamples”. To do this we will use the show_best() function of the tune package.

tune::show_best(resample_fit, metric = "rmse", "rsq")

# A tibble: 1 x 5
  .metric .estimator  mean     n std_err
  <chr>   <chr>      <dbl> <int>   <dbl>
1 rmse    standard    2.08    10   0.147

Tuning

Now let’s try some tuning.

Let’s take a closer look at how the monitor values vary with latitude and longitude.

train_pm %>% 
  dplyr::select(value, lon, lat) %>% 
  tidyr::pivot_longer(cols = c(lon, lat), 
                      names_to = "predictor", values_to = "loc_value") %>% 
  ggplot(aes(x = loc_value, value)) + 
  geom_point(alpha = .2) + 
  geom_smooth(se = FALSE) + 
  #scale_y_log10() +
  facet_wrap(~ predictor, scales = "free_x")

We can see that there does not appear to be a single linear relationship for either of these predictors. Thus we might want to think about using splines or this(https://towardsdatascience.com/numerical-interpolation-natural-cubic-spline-52c1157b98ac) or just this(https://tidymodels.github.io/tune/articles/getting_started.html) or this(https://www.psych.mcgill.ca/misc/fda/ex-basis-b1.html) to model the relationship in our training data more closely. For example for the latitude plot (left) if we had 2 lines and one breakpoint called a knot around 40, with the first line having a positive slope and the second with a negative slope this would fit the data more similarly to the blue line shown in the figure.

We can tune for the number of knots by using a step function in the recipes package called step_ns() where ns stands for natural splines. In order to tune for the number of knots or degrees of freedom, we can set the deg_free argument to tune(). This is helpful, becuase we aren’t exactly sure how closely we should be following the relationship with the value and our longitude and latitude data in our training data to achieve good accuracy yet keep our model generalizable for other data.

This is when our cross validation methods become really handy. We can test out different values for the deg_free argument and see how our model performance varies across our training folds to try to find the optimal value.

We will update our recipe to add these steps. It is a good idea to do this for individual predictors because you can name each with the tune argument so that you can keep track of it later. We can see what we intend to tune with the parameters() function of the dials package.

See here for more information about implementing this in tidymodels.

simple_rec %<>%
  step_ns(lon, deg_free = tune("lon df")) %>%
  step_ns(lat,  deg_free = tune("lat df"))
# simple_rec %<>%
#   step_ns(lat,  deg_free = tune())
# simple_rec

pm_param <-dials::parameters(simple_rec)
pm_param

Collection of 2 parameters for tuning

     id parameter type object class
 lon df       deg_free    nparam[+]
 lat df       deg_free    nparam[+]

Genearlly you could use the grid_*() functions of the dials package to create the different combinations of degrees of freedom to test for both variables to optimize the model. In our case we can visably see that if we add more than say 4 or 5 degrees of freedom we will likely overfit the data. So instead of using these functions we will create our own grid using the base seq() and expand.grid() functions.

#an example of what you could do:
#spline_grid <-dials::grid_regular(pm_param, levels = 3)
df_vals <- seq(1, 5, by = 2)
spline_grid <- expand.grid(`lon df` = df_vals, `lat df` = df_vals)
spline_grid

  lon df lat df
1      1      1
2      3      1
3      5      1
4      1      3
5      3      3
6      5      3
7      1      5
8      3      5
9      5      5

Now we will tune this hyper-parameter (degrees of freedom) for both the lat and lon variables using our cross validation folds. To do this we will use the tune_grid() function of the tune package.

df_tuning <-lm_PM_model %>% 
  tune::tune_grid(simple_rec, resamples =vfold_pm, 
                  grid = spline_grid)

#df_tuning <-PM_wflow %>% tune::tune_grid(resamples =vfold_pm, 
 #                                        grid = spline_grid, 
  
#                                       param_set =pm_param)

df_tuning

#  10-fold cross-validation 
# A tibble: 10 x 4
   splits           id     .metrics          .notes           
 * <list>           <chr>  <list>            <list>           
 1 <split [525/59]> Fold01 <tibble [18 × 5]> <tibble [18 × 1]>
 2 <split [525/59]> Fold02 <tibble [18 × 5]> <tibble [18 × 1]>
 3 <split [525/59]> Fold03 <tibble [18 × 5]> <tibble [18 × 1]>
 4 <split [525/59]> Fold04 <tibble [18 × 5]> <tibble [18 × 1]>
 5 <split [526/58]> Fold05 <tibble [18 × 5]> <tibble [18 × 1]>
 6 <split [526/58]> Fold06 <tibble [18 × 5]> <tibble [18 × 1]>
 7 <split [526/58]> Fold07 <tibble [18 × 5]> <tibble [18 × 1]>
 8 <split [526/58]> Fold08 <tibble [18 × 5]> <tibble [18 × 1]>
 9 <split [526/58]> Fold09 <tibble [18 × 5]> <tibble [18 × 1]>
10 <split [526/58]> Fold10 <tibble [18 × 5]> <tibble [18 × 1]>

df_tuning %>%
  collect_metrics()

# A tibble: 18 x 7
   `lon df` `lat df` .metric .estimator  mean     n std_err
      <dbl>    <dbl> <chr>   <chr>      <dbl> <int>   <dbl>
 1        1        1 rmse    standard   2.08     10  0.147 
 2        1        1 rsq     standard   0.433    10  0.0504
 3        1        3 rmse    standard   1.99     10  0.149 
 4        1        3 rsq     standard   0.483    10  0.0483
 5        1        5 rmse    standard   2.00     10  0.151 
 6        1        5 rsq     standard   0.477    10  0.0475
 7        3        1 rmse    standard   2.00     10  0.160 
 8        3        1 rsq     standard   0.475    10  0.0557
 9        3        3 rmse    standard   1.91     10  0.159 
10        3        3 rsq     standard   0.519    10  0.0508
11        3        5 rmse    standard   1.90     10  0.159 
12        3        5 rsq     standard   0.526    10  0.0514
13        5        1 rmse    standard   2.00     10  0.162 
14        5        1 rsq     standard   0.469    10  0.0576
15        5        3 rmse    standard   1.92     10  0.166 
16        5        3 rsq     standard   0.512    10  0.0565
17        5        5 rmse    standard   1.90     10  0.171 
18        5        5 rsq     standard   0.519    10  0.0613

collect_metrics(df_tuning)

# A tibble: 18 x 7
   `lon df` `lat df` .metric .estimator  mean     n std_err
      <dbl>    <dbl> <chr>   <chr>      <dbl> <int>   <dbl>
 1        1        1 rmse    standard   2.08     10  0.147 
 2        1        1 rsq     standard   0.433    10  0.0504
 3        1        3 rmse    standard   1.99     10  0.149 
 4        1        3 rsq     standard   0.483    10  0.0483
 5        1        5 rmse    standard   2.00     10  0.151 
 6        1        5 rsq     standard   0.477    10  0.0475
 7        3        1 rmse    standard   2.00     10  0.160 
 8        3        1 rsq     standard   0.475    10  0.0557
 9        3        3 rmse    standard   1.91     10  0.159 
10        3        3 rsq     standard   0.519    10  0.0508
11        3        5 rmse    standard   1.90     10  0.159 
12        3        5 rsq     standard   0.526    10  0.0514
13        5        1 rmse    standard   2.00     10  0.162 
14        5        1 rsq     standard   0.469    10  0.0576
15        5        3 rmse    standard   1.92     10  0.166 
16        5        3 rsq     standard   0.512    10  0.0565
17        5        5 rmse    standard   1.90     10  0.171 
18        5        5 rsq     standard   0.519    10  0.0613

show_best(df_tuning, metric = "rmse", n =1)

# A tibble: 1 x 7
  `lon df` `lat df` .metric .estimator  mean     n std_err
     <dbl>    <dbl> <chr>   <chr>      <dbl> <int>   <dbl>
1        5        5 rmse    standard    1.90    10   0.171

Linear Regression Model with PCA

lm_PCA_rec <-recipe(train_pm) %>%
    update_role(everything(), new_role = "predictor")%>%
    update_role(value, new_role = "outcome")%>%
    update_role(id, new_role = "id variable") %>%
    update_role("fips", new_role = "county id") %>%
    step_dummy(state, county, city, zcta) %>%
    step_pca(all_predictors()) 

We wtill want to use the lm package for our regression so we can use the same model object:

lm_PM_model

Linear Regression Model Specification (regression)

Computational engine: lm 

We can create another workflow:

pca_wflow <-workflows::workflow() %>%
           workflows::add_recipe(lm_PCA_rec) %>%
           workflows::add_model(lm_PM_model)
pca_wflow

══ Workflow ═════════════════════════════════════════════════════════════════════════════════
Preprocessor: Recipe
Model: linear_reg()

── Preprocessor ─────────────────────────────────────────────────────────────────────────────
2 Recipe Steps

● step_dummy()
● step_pca()

── Model ────────────────────────────────────────────────────────────────────────────────────
Linear Regression Model Specification (regression)

Computational engine: lm 

Fit the cross validation samples:

resample_pca_fit <-tune::fit_resamples(pca_wflow, vfold_pm)

Look at the performance:

collect_metrics(resample_pca_fit)

# A tibble: 2 x 5
  .metric .estimator  mean     n std_err
  <chr>   <chr>      <dbl> <int>   <dbl>
1 rmse    standard   2.69     10  0.244 
2 rsq     standard   0.214    10  0.0511

And we can compare this with our previous performance:

collect_metrics(resample_fit)

# A tibble: 2 x 5
  .metric .estimator  mean     n std_err
  <chr>   <chr>      <dbl> <int>   <dbl>
1 rmse    standard   2.08     10  0.147 
2 rsq     standard   0.433    10  0.0504

Let’s review everything:

check_new_values: This check will break the bake function if any of the checked columns does contain values it did not contain when prep was called on the recipe. If the check passes, nothing is changed to the data

check_range creates a specification of a recipe check that will check if the range of a numeric variable changed in the new data.

parameter vs hyperparameter

prepper for cross validation?

great blog about cross validation etc https://towardsdatascience.com/train-test-split-and-cross-validation-in-python-80b61beca4b6

Data Visualization

Summary

We have evaluated average consumption estimates of 15 dietary factors with probably non-communicable disease (NCD) risk from 195 different countries around the world. To do so we imported data from a PDF using the pdftools package, as well as data from two CSV files using readr. We used tidyverse packages such as dplyr, stringr, and tidy to clean and join the data from the PDF with the CSV files.

We learned that Regression is a powerful and flexible statistical tool that simplifies or estimates the relationships between variables using a mathematical model. We learned about the utility of the regression to compare groups, look for associations between variables, and to predict outcomes based on multiple predictor or explanatory variables. We then compared this to other popular tests like the \(t\)-test and the ANOVA. We learned that these tests are actually equivalent to specialized types of regressions.

Our statistical analysis focused on evaluating differences in the consumption of red meat around the world between females and males and across different age groups. First we looked at the assumptions of \(t\)-tests and regressions, and determined that the relative percentage data of red meat consumption to the optimal guideline suggested amount was right skewed. We learned that we could transform the data by taking the log of these values to achieve more normally distributed data. To compare males and females we used a \(t\)-test and learned that a \(t\)-test is a specialized form of a linear regression. To compare the 15 different age groups we used an ANOVA and learned that the ANOVA is also a specialized form of linear regression. We examined how we obtained the same results using either statistical test. This was also the case if we looked at the effect of gender and controlled for the paired country structure in the data by either including location_name in the model as another term or by using a mixed effects model to control for this structure as a random effect but not specifically test for the influence of location_name on red meat consumption estimates. We learned that fixed effects are those that we wish to evaluate, while random effects are those that may influence the relationships of our variables of interest but that we do not wish to actively evaluate. Using these tests and models, we determined that males consume more red meat than women on average around the world.

Our ANOVA analysis of age determined that indeed there at least one age group consumed a significantly different amount of red meat compared to the other age groups, and this was still the case when we controlled location_name. However, we learned that we could that the ANOVA does not provide information about which age groups are different. We learned how the regression however could provide some comparisons of different age groups relative to the reference age group. Furthermore, our data visualizations allowed us to determine that in general red met consumption appears to be higher in the younger age groups relative to the older age groups.

Finally, we also looked at differences in red meat consumption between the different countries and saw in our ANOVA analysis and our regression analysis that there were significant differences. We were able to use a regression that included sex, age_group_name, and location_name to evaluate the influence of each of the three demographic factors on consumption while controlling or accounting for the other two. Our results demonstrated that all three influenced or were associated with red meat consumption.

In preforming our statistical analyses we learned about the assumptions of the \(t\)-test, the regression, and the ANOVA. We also learned about important methods to tests these assumptions.

\(t\)-test assumptions:

1. Normality of the data for both groups (this is not as much of an issue if the number of observations is relatively large total n>30 - can evaluate by plotting the distribution and by creating Q-Q plots)
2. Equal variance between the two groups (make sure you do the correct test if the data is not normal)
3. Balanced sample sizes of the two groups
4. Independent observations (or independent paired observations)

We can evaluate if our data is normally distributed by plotting the distribution and by creating [Q-Q plots](Q-Q Plots to compare the distribution of our data to the theoretical normal distribution.

If our data is not normally distributed, we can consider these options:

1. We can still perform a \(t\)-test if our n is large
2. We can transform the data before performing a \(t\)-test
3. We can use a nonparametric test (Wilcoxon signed rank test, the Wilcoxon rank sum test, and the Two-sample Kolmogorov-Smirnov (KS) test)
4. We can perform a \(t\)-test with resampling methods (which should be especially considered when the groups are imbalanced)

See this case study for more information on \(t\)-test assumptions.

We learned that we can test if 2 groups have equal variance using:
1) the F test with var.test()
2) Mood’s test using mood.test() (use if the data is not normally distributed)

Linear regression assumptions:

L (linear) - There is a linear relationship between the variables.
I (independent) - The samples are independent from one another.
N (normal) - The residuals are normally distributed.
E (equal variances) - The variance of the residuals of the groups is similar.
It is also important that predictor variables are not correlated with one another.

ANOVA assumptions:

1. Normality of the data for all tested groups (less of an issue if the number of observations is relatively large total n>30)
2. Equal variance between the groups - aka Homogeneity of variance (make sure you do the correct test if the data is not normal)
3. Balanced sample sizes of the groups
4. Independent observations (or independent paired observations)

We learned about three tests for examining the equality of variance of 3 or more groups: 1) Bartlett’s test (works well if the data appears to be normally distributed) 2) Fligner-Killeen test is nonparametric and does not assume normality 3) Levene’s test, is more robust to violations of normality than the Bartlett’s test, but not as robust as the Fligner- Killeen test

Using the ggplot2 package we were able to visualize trends in the data and to compare consumption of these dietary factors in the US with that of the other countries. We see that the populations in many countries are over-consuming foods that are associated with health risk when over-consumed. In particular processed meat and sugar-sweetened beverages appear to be the most over consumed. Importantly both of these appear to be consumed at higher quantities by males and younger adults. People in the US appear to consume less sugar-sweetened beverages than other countries, however, people are still over-consuming. Processed meat however appears to be especially bad in the US. In terms of food that need to be consumed in adequate amounts to overcome health risk, nearly all countries for all factors are not reaching guideline levels. However, there are some countries consuming more than adequate amounts of legumes, vegetables, fruits and fiber. People in the US appear to eat more milk products and consume more omega-3 fatty acid and calcium rich foods than other countries. All countries including the US consume very low levels of polyunsaturated fatty acids. These polyunsaturated fatty acids are abundant in seeds, nuts, avocados, as well as fish. Likely the low level of consumption of nuts and seeds contributes to these low polyunsaturated fatty acid estimates. The supplementary table included in the article suggests that poor consumption of polyunsaturated fatty acids is associated with ischemic heart disease. The article takes this data further to evaluate the association of consumption levels of these foods with mortality.

Analyses like the one in our case study are important for defining which groups could benefit the most from interventions, education, and policy changes when attempting to mitigate public health challenges. You can see in the article however that many additional considerations would be involved to perform a more thorough analysis to adequately understand the data enough to recommend policy changes.

Suggested Homework

Students can evaluate consumption estimates of another dietary factor besides red meat.

Helpful Links

review of tidymodels

guide for preprocessing with recipes

guide for using GGally to create correlation plots guide for using parsnip to try different algorithms or engines recipe functions

Terms and concepts covered:

Tidyverse
RStudio cheatsheets
Inference
Regression
Different types of regression
Ordinary least squares method
Residual

Packages used in this case study:

Package	Use
here	to easily load and save data
readr	to import the CSV file data
dplyr	to arrange/filter/select/compare specific subsets of the data
skimr	to get an overview of data
summarytools	to get an overview of data in a different style
pdftools	to read a PDF into R
magrittr	to use the %<>% pipping operator
purrr	to perform functions on all columns of a tibble
tibble	to create data objects that we can manipulate with dplyr/stringr/tidyr/purrr
tidyr	to separate data within a column into multiple columns
ggplot2	to make visualizations with multiple layers

Do I need to talk about machine learning in general more… classification vs prediction?